Linux capabilities #81
Conversation
It's a preparatory commit to reflect upcoming changes in how capabilities are checked under Linux in presence of libcap-ng. No functional change. Signed-off-by: Oleksandr Natalenko <[email protected]>
|
This feels very Linux-specific. What do you think about adding a new argument flag that skips the check, and then it is up to the user to make it work anyway |
|
If we do it like this I think it makes sense to exit only after all checks are done, so that the user does not keep getting new errors after fixing the first one.
|
Under Linux, a process may not be run under root, yet it may have a permission to do what a superuser may do given specific capabilities are granted. This commit makes iodine not depend on EUID being 0 in order to run properly. Instead, in presence of libcap-ng, the following capabilities are being checked: * `CAP_NET_BIND_SERVICES` for server to bind to a port, lower than `/proc/sys/net/ipv4/ip_unprivileged_port_start` * `CAP_NET_ADMIN` to operate on a TUN device * `CAP_SETUID` and `CAP_SETGID` in case server is configured to change the user it runs on behalf of This change is handy if iodine is being run under a non-root user, provided `AmbientCapabilities=` and `CapabilityBoundingSet=` of systemd are employed in the first place. Fixes: yarrick#80 Signed-off-by: Oleksandr Natalenko <[email protected]>
pfactum
force-pushed
the
linux-capabilities
branch
from
c25eed6 to
ebf4e7e
Compare
That can be an additional argument that does not intersect with proposed changes. Proposed changes allow more granular capabilities checking and reporting. |
Thanks for the suggestion, forced-pushed with this change, please check.
Nope. Having UID 0 doesn't guarantee having all the required capabilities. On Linux |
Address #80.