It was <2022-06-27 pon 23:36>, when Lukasz Stelmach wrote: [...] > - children DO NOT inherit capabilites from systemd --user (they do now) > > This last is a problem because I'd like to avoid modifications of all > service files. I tried to drop inheritable caps before execve() (in > exec_child()) but as described in capabilities(7) this results in > dropping caps from the ambient set too, which means systemd --user > doens't get what it needs. > > Is there anything I am missing? Is there any way to start a service with > UID!=0, some capabilities set but not implicitly inheritable by > processes spawned by the service? OK, I added (PoC) support for InheritableCapabilities option to user.conf. Now, when systemd --user starts it sets inheritable capabilities to a configured value right here[1]. My implementation, however, has a slight problem because it changes the default behavior (InheritableCapabilities not set in user.conf). When the option is not set, the variable which keeps its value in src/core/main.c (let's call it arg_inheritable_capabilities) is set to 0 which means all the inheritable capabilities are dropped. Which isn't how systemd --user works now (it keeps the inheritable set untouched). What default value to use to mark the option as unset in the configuration file and avoid changing it in any way? -1, CAP_ALL+1? [1] https://github.com/systemd/systemd/blob/aaec2216602ce3a26b7bca30eaf28e525ef5e762/src/core/main.c#L2150 -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
Attachment:
signature.asc
Description: PGP signature
