Problem with syncOwnership

[chatziko (Kostas)]

Hi all, I’m trying the new interesting syncOwnership option. I’ve setup the capabilities:

$ ls -l /usr/bin/syncthing 
-rwxr-xr-x 1 root root 23605832 Aug 16 11:01 /usr/bin/syncthing

~$ getcap /usr/bin/syncthing
/usr/bin/syncthing = cap_chown,cap_fowner+ep

I create a file ~/Sync/ff owned by root in one machine, but it’s not getting synced in the other. I’m getting the following error in the systemd log:

syncthing[377010]: [A2444] INFO: Puller (folder "Default Folder" (default), item "ff"): syncing: lchown /home/vagabond/Sync/.syncthing.ff.tmp: operation not permitted

Seems like chowning the file fails. Anything I am missing?

The above was tried in Ubuntu 20.04.5, using v1.21.0 from the official apt repo, with a simple 2-machine sync with default settings (and syncOwnership, syncOwnership set to true).

[calmh (Jakob Borg)]

We have a bunch of hardening options in the systemd file, maybe they interfere with the capabilities; or maybe capabilities need to be stated some other way in the systemd file?

[chatziko (Kostas)]

Thanks for the quick response, I was also suspecting this. Digging some more it seems that systemd is indeed the culprit:

I first launch with systemctl start syncthing@vagabond.service and query the capabilties:

# pgrep syncthing
403025
403033
# cat /proc/403033/status |grep Cap
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000

No caps are active!

Then I manually run syncthing from the terminal (as non-root):

# pgrep syncthing
403580
403588
# cat /proc/403588/status |grep Cap
CapInh:	0000000000000000
CapPrm:	0000000000000009
CapEff:	0000000000000009
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000

Note the difference in CapEff.

0x0000000000000009=cap_chown,cap_fowner

So I’ll try the various systemd options to figure it out…

PS. ideally it could be possible to set the caps only in systemd (not in the executable). This would allow to use syncOwnership without messing with system updates!

[Nummer378 (Max)]

IIRC systemd will (by default/depending on hardening) not grant capabilites to processes, even if set in the binary’s metadata.

This is likely caused by the hardening option NoNewPrivileges.

You likely need to set CapabilityBoundingSet (and perhaps AmbientCapabilities too) in syncthing’s systemd service to grant it.

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Capabilities

To avoid having to edit syncthing’s systemd service file directly (which will cause conflicts on upgrades), you can use systemctl edit to create an override file (to be applied on top of the existing service file).

# systemctl edit syncthing@vagabond.service

then add CapabilityBoundingSet and AmbientCapabilities (with your caps as value, see the documentation) in the [Service] section.

[chatziko (Kostas)]

Ok, here’s a simple solution that works for me:

• Do not set any capabilities in the executable (awesome, no problems with upgrades)
• systemctl edit syncthing@<username>, add

  [Service]
  AmbientCapabilities=CAP_CHOWN CAP_FOWNER
  

Systemd will set the capabilities and owner syncing works. Maybe this can be added to the doc.

Thanks for this great feature!

[acolomb (André Colomb)]

In fact, it should be added to our systemd template unit file IMHO, probably commented out by default.