Bug#1001147: syncthing.service appears to be enabled for all users

Francois Marier

unread,

Dec 5, 2021, 4:00:04 AM12/5/21

to

Package: syncthing
Version: 1.18.0~ds1-1
Severity: normal

I've noticed a couple of odd things in my logs since a recent SyncThing
upgrade.

The first one is that a new SyncThing device I can't identify is now being
advertised from my laptop. The ID I see being advertised is not the one I
use on that device.

Secondly, I see the following in my logs:

Dec 4 07:40:13 akranes syncthing[1962943]: WARNING: Failure on home directory: mkdir /bin/.config: permission denied

which suggests that SyncThing is trying to run with one of the system user
accounts that have /bin/ as their homedir:

$ grep :/bin: /etc/passwd
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin

Finally, I found Sync directories in odd places:

/var/lib/gdm3/Sync
/var/spool/email-reminder/Sync

I'm not an expert in systemd service files, but this suggests to me that
SyncThing is being run from many user accounts which really shouldn't run
it. They should especially not creating new directories and start sharing
them on the network.

Francois

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages syncthing depends on:
ii init-system-helpers 1.60
ii libc6 2.32-4

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Alexandre Viau

unread,

Dec 19, 2021, 4:20:03 PM12/19/21

to

Hello/Salut Francois,

Could it be that you globally enabled the syncthing systemd user unit?

Can you please show us the output of:
- $ ls -l /etc/systemd/user/default.target.wants/

Thanks,

--
Alexandre Viau
av...@debian.org

Alexandre Viau

unread,

Dec 19, 2021, 5:30:03 PM12/19/21

to

Ah, it was dh-systemd enabling the user unit by default.

Since the user unit is not the only way to use syncthing, I would say
that disabling it by default is a better choice.

I have uploaded a new version that does exactly that.

Thanks the report,

--
Alexandre Viau
alex...@alexandreviau.net

Francois Marier

unread,

Dec 19, 2021, 5:40:03 PM12/19/21

to

On 2021-12-19 at 13:12:58, Alexandre Viau (av...@debian.org) wrote:
> Can you please show us the output of:
> - $ ls -l /etc/systemd/user/default.target.wants/

I do have Syncthing in there:

lrwxrwxrwx 1 root root 35 Jul 22 2019 dunst.service -> /usr/lib/systemd/user/dunst.service
lrwxrwxrwx 1 root root 38 Sep 27 2020 pipewire.service -> /usr/lib/systemd/user/pipewire.service
lrwxrwxrwx 1 root root 40 Aug 23 2019 pulseaudio.service -> /usr/lib/systemd/user/pulseaudio.service
lrwxrwxrwx 1 root root 39 Dec 3 00:32 syncthing.service -> /usr/lib/systemd/user/syncthing.service
lrwxrwxrwx 1 root root 47 Sep 3 11:44 tracker-extract-3.service -> /usr/lib/systemd/user/tracker-extract-3.service

I don't remember manually enabling this myself though. It's possible I did
and forgot, but I suspect it happened when I upgraded the package a few
weeks ago.

Francois

--
https://fmarier.org/

Francois Marier

unread,

Dec 19, 2021, 6:00:05 PM12/19/21

to

On 2021-12-19 at 14:22:03, Alexandre Viau (alex...@alexandreviau.net) wrote:
> Ah, it was dh-systemd enabling the user unit by default.
>
> Since the user unit is not the only way to use syncthing, I would say
> that disabling it by default is a better choice.

The other thing is that I'd say it only makes sense to run the Syncthing
user service for real users, not for system user accounts (e.g. the ones
used for cron and the likes).

Francois

--
https://fmarier.org/

Brendon Higgins

unread,

Jan 14, 2022, 9:30:04 AM1/14/22

to

Hi,

I just noticed the symptoms of this on my own system. Does every installation
affected by this bug need manual intervention to undo the automatically-enabled
user unit, or should the fixed package do that itself? If the former, for those
not familiar (myself included), could you suggest the appropriate incantation
to remove the user unit?

Thanks,
Brendon