Systemd: Bind to privileged port without altering upstream service file
Saturday, June 15 2019 · Lesezeit: 2 Minuten · 424 Wörter · Tags: syncthingsystemd Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!I’m using syncthing to sync files to all my devices. It comes with a webinterface accessable over port 8384. I don’t like websites which are not accessable over port 80 or 443. Normally I use nginx to proxy requests. For me that’s hassle free because I’m using ansible to spin up nginx installations. Yet it’s unnecessary overhead.
An unprivileged application usually can’t bind to ports below 1024. My syncthing installation runs with user privileges and is - as far as I know - not able to drop privileges like nginx.
Possible solutions for my problem:
- Using nginx as proxy => Useless overhead
- Using ip6tables to rewrite packets => My way of doing shit like this in IPv4 which should not be done with IPv6 according to the internet
- Using my firewall to rewrite packets => Would not work in a layer 2 network when traffic isn’t forced over the firewall
- Using systemds AmbientCapabilities feature to allow an application with user privileges to bind ports below 1024 => Let’s try that
Oh! Did I mention that my syncthing is running IPv6 only? :-)
I decided to tackle the problem with systemd. But then I stumbled over a problem: The service file needs to be altered but I’m using the one the package maintainer/upstream provides. I’d have to manually merge possible changes from time to time. And my lazy ass won’t do that for sure.
Luckily the systemd developers have a solution for it: You can extend any service file without altering the upstream source. This is done by creating a directory like /etc/systemd/system/sshd.service.d. You can put .conf files into it with parts you want to change. In my syncthing case I’ve created the directory /etc/systemd/system/syncthing@.service.d and put a file capabilities.conf in it with the following content:
[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
After reloading the systemd daemon (systemctl daemon-reload), configuring syncthing to listen on port 443 and restarting syncthing I got the following log message:
GUI and API listening on [2001:db08:ff98:7137:5054:ff:fe33:aabb]:443
Cool! Now I don’t have to manage anything and no update would break my setup.
If the @-sign bothers you: As mentioned above my syncthing is started with user privileges and context. My command for that is systemctl start syncthing@veloc1ty.service. If you perform a status request to that service you will get a line with Loaded: loaded (/usr/lib/systemd/system/syncthing@.service; enabled; vendor preset: disabled). As you can see the upstream service filename is syncthing@.service. So I took that name and created the corresponding directory syncthing@.service.d.
Sources
Du hast einen Kommentar, einen Wunsch oder eine Verbesserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.
🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg) Zurück