[systemd-devel] capabilities for systemd --user

[Lukasz Stelmach]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220628/2638d34c/attachment.sig>