Setting file capabilities in deb package fails

Question

So, there is my piece of software, that has to be distributed via deb-packages, it contains a small custom server. That server requires ability to listen on a priviledged port, because explaining to a customer something like "we've got non-standard RTSP port because could not handle the permissions properly" sounds afwful.

Okay, first I'm trying to test the concept and print in the terminal the following:

setcap CAP_NET_BIND_SERVICE=+ep /opt/path/my_binary 

Everything works fine, so seemingly the same command should work in my postinstall script, lets call it postinst.1.server:

...
...
printf "something" > /opt/somewhere || exit 15
setcap CAP_NET_BIND_SERVICE=+ep /opt/path/my_binary || exit 16

Installing goes without errors, so the command must have worked properly... but no, the port is not available to the server due to lack of permissions (executing the command manually does the trick again, of course).

Okaaaay... so there I'm going to the systemd, because the target server's executable is designed to be managed by a service. The custom systemd config is the following:

[Unit]
Description=Some description
After=network.target
Requires=postgresql.service

[Service]
Type=notify
WorkingDirectory=/opt/some_path
Restart=always
RestartSec=15000ms

User=server_user
Group=server_user

Environment=XAUTHORITY=/tmp/.Xauth
Environment=DISPLAY=:0

ExecStart=/opt/path/server_executable run
TimeoutStartSec=10000ms
WatchdogSec=6666ms
TimeoutStopSec=7000ms

# My new attempt to fix capabilities
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID

[Install]
WantedBy=multi-user.target                             

The optimistic hope was that server_executable launches my_binary thus the child process could inherit the capabilities... no luck there.

---

Currently I'm still trying to set the desired capability in the postinstall script, but don't have the slightest idea why the command has effect only after manual execution.

Some "debugging" led me towards some more strange results:

• Writing getcap /opt/ksvd4/ksvd4_portale.exe 2>&1 in postinstall script resulted in printing the correct capabilities, but they occured to be gone by the end of the installation (checked manually afterwards)
• Using -v option (verification) immediately after setter command call also results in "OK", proving the capability disappearance.

Would be grateful if anyone could point me to the proper way of doing the trick or at least find the hidden problem that spoils the current solution attempt.

OS is Ubuntu 16.04 if it matters somehow.

Answer 1

Not a full answer, but may help.

If the executable will have this capability, then you should make it only executable by a certain group (to prevent random users from grabbing the port).

If you are creating a new program, then you should make it capability aware (use capability system calls, to move capabilities in and out of the effective set). So no need for the effective bit to be set in the file capabilities.

File capabilities (and setuid/setgid ), only work on statically linked binaries.

Capabilities persist across new processes (fork), but not across new executable/programs (exec). You can use ambient capabilities to persist across exec (you will have to make the caller (of exec) capability aware (write the code with capabilities in mind).