Open markboots opened 1 year ago
What kind of kernel and environment was this under?
This is on Debian Buster, kernel 4.19.0-23-cloud-amd64, using the Debian AWS AMI.
Could be the cloud/AWS kernel not allowing CAP_NET_ADMIN then
Is there anything in rtpengine that will fail without having CAP_NET_ADMIN? If the daemon launches are we good to go, or could there be runtime failures later?
(Note: It looks like this is only a Debian buster issue; the default systemd scripts worked fine on Debian bullseye, 5.10.0-20-cloud-amd64.)
CAP_NET_ADMIN is needed for managing the iptables rules if that feature is enabled (see iptables-chain
option, which is unrelated to the kernel module). I don't think it's needed for anything else.
And we've been using this on both bullseye and buster with the stock kernels just fine, so this is probably something specific to that cloud kernel.
I had the same problem as @markboots on a plain Debian Buster installation and I can confirm that commenting out AmbientCapabilities in the systemd service file works.
However, I was not pleased by the solution and experimented some more and found that I could keep AmbientCapabilities enabled if I commented out CapabilityBoundingSet=(empty here) at line 59 of the systemd file (https://github.com/sipwise/rtpengine/blob/master/debian/ngcp-rtpengine-daemon.service) or at least setting CapabilityBoundingSet to anything but an empty set, such as the example on line 65 of the same file.
So for me this works:
#CapabilityBoundingSet=
AmbientCapabilities=CAP_NET_ADMIN CAP_SYS_NICE
as well as
CapabilityBoundingSet=CAP_CHOWN CAP_DAC_OVERRIDE CAP_SETGID CAP_SETUID CAP_FOWNER CAP_NET_ADMIN CAP_SYS_NICE
AmbientCapabilities=CAP_NET_ADMIN CAP_SYS_NICE
but this doesn't:
CapabilityBoundingSet=
AmbientCapabilities=CAP_NET_ADMIN CAP_SYS_NICE
We're using the Debian packages at https://dfx.at/rtpengine/
Using the default systemd startup script, rtpengine-daemon fails to start:
We resolved this by commenting out the following Ambient Capabilities in /lib/systemd/system/rtpengine-daemon.service:
Contrary to the NOTE, this change succeeds at launching successfully, running as the non-root
rtpengine
user.