Owner and permissions when running as unprivileged user

Support
1

I’m having trouble getting the setup right when running the Syncthing daemon as an unprivileged user on Linux. In my case it’s Gentoo Linux, the install from the public repo runs Syncthing as “syncthing:syncthing”.

Now, I’d like to sync directories of different users located in their home directores. For example, let’s assume the following directory to be synced:

drwxr-xr-x  jdoe:jdoe  /home/jdoe/shared

Obviously, Syncthing can’t write into this directory, so for testing, let’s go 0777:

drwxrwxrwx  jdoe:jdoe  /home/jdoe/shared

In order for the synced files to get the ownership of the parent assigned, I’ve checked the advanced directory setting “Copy Ownership From Parent” and granted capabilities to the “syncthing” binary.

setcap "cap_chown,cap_fowner=+ep" /usr/bin/syncthing

I can now sync files in the synced directory and the parent owner is assigned.

However, when I sync a subdirectory, it gets default permissions assigned e.g.:

drwxr-xr-x  jdoe:jdoe  /home/jdoe/shared/subdirectory

And any files inside this subdirectory won’t be synced anymore because, again, Syncthing can’t write into the subdirectory.

(A solution would be changing the umask of the Syncthing daemon to 000, however, it defeats a bit the purpose of having any access control.)

I guess I’m missing a bit here since I’ve seen others playing with capabilities and reaching a working solution. Any ideas what this missing bit could be?

Thanks for your help!

2

Why do you expect Syncthing to assign 777 permissions when your umask is 022?

What is the goal of your access control? If it’s e.g. to allow only Syncthing and jdoe to access, run Syncthing as jdoe. If it’s the same, but you have more users than jdoe, I’d recommend running multiple Syncthing instances. Another option would be to create a group for every user, and add the syncthing user to all those groups, chown to user:usergroup and use 002 umask.

3

Why do you expect Syncthing to assign 777 permissions when your umask is 022?

I don’t, it’s just the way things are setup at this point.

What is the goal of your access control? If it’s e.g. to allow only Syncthing and jdoe to access, run Syncthing as jdoe.

That’s my current workaround, but I’ll need synching for another user at some point.

And I had to change the owner on all of Syncthing’s files in /var/lib (incl. config) which will be reset and break when Gentoo’s package manager updates Syncthing.

If it’s the same, but you have more users than jdoe, I’d recommend running multiple Syncthing instances.

Same problem when the package manager updates Syncthing.

Another option would be to create a group for every user, and add the syncthing user to all those groups, chown to user:usergroup and use 002 umask.

For this to work, files created by the user should use 002 mask as well to make sure Syncthing can not only push it to the remote but also modify/delete it when changed on the remote. Maybe setfacl could do that trick.

I’ll figure something out, apparently, I haven’t overlooked the silver bullet, there simply isn’t any – as often when having fun with permissions.

4

You should have a service definition per user, which can use the package manager installed binaries, but each has their own config/database.

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.