Running web GUI on port 443 (working) - Explanation needed

General
1

Hello everyone,

I wanted to run Syncthing under the 443 port directly. This was mainly, so I can use easy DNS names and since everything is run through an ZTNA there is no security concern on my end.

I created a syncthing user, where the data is also stored, and added the capabilities to the Binary with: setcap CAP_NET_BIND_SERVICE=+eip and I can run the binary under the syncthing user on 443 fine. Tested with sudo -u syncthing -i and su syncthing

I then proceeded to change the system-unit to the following: (only including changes, so it’s not a wall of text)

[Service]
User=syncthing  
Group=syncthing 
ExecStart=/home/syncthing/syncthing-1.24.0/syncthing serve --no-browser --no-restart --

# Hardening
#NoNewPrivileges=true    # --- commented this

I ran into the issue that syncthing still could not bind to Port 443 because - Permission Denied - even after adding Capabilities.

Only after adding this to the Systemd unit:

AmbientCapabilities=CAP_NET_BIND_SERVICE

It does work. I’ve read up on capabilities, but can someone explain to me why they need to be passed in the ambient set even after they were manually added to the binaries effective set?

My CAP understanding is still a bit unclear.

Many Thanks in Advance.

2

The gist is that systemd inhibits setcap/setuid file permissions by default.

Generally file permissions are not recommended, because they get reset whenever the binary is overwritten - which typically happens on each upgrade. Setting capabilities via systemd is the recommended way (syncOwnership — Syncthing documentation)

PS: You can also use systemctl edit to make changes to a service unit without overwriting the original. This enables you to keep that in sync during upgrades while still applying your own changes.

2 Likes
3 
systemctl edit --full syncthing@xxxxx

The --full flag is a lot easier. The overwrite syntax of systemd is a bit weird IMHO.

2 Likes
4

Okay - thanks for that info… i have a but tho…

I tried to use Resilio-Sync before Syncthing. There I only had to use setcap to get it to run via systemd under the rslsync user bound to 443, with no ambient capabilities set trough the Systemd unit. I had to use setcap becaues it didn’t work before that. Where is the Discrepencey here does it have to do with Capabilit awareness?

5

I don’t know Resilio so I don’t know :person_shrugging:. It’s possible that syncthing’s monitor process interferes if the setcap-gained capabilities are not inheritable for whatever reason, or the service files are configured differently or something else entirely.