On Mo, 27.06.22 23:36, Lukasz Stelmach ([email protected]) wrote: > Hi, > > I need an apparently exotic configuration and I don't know how to > approach the problem. Here are the requirements: > > - [email protected] (systemd --user) > + runs with Priv SMACK label (SmackProcessLabel in [email protected]) > + has cap_mac_admin (and a few other capabilities) to assign SMACK > labels to its children (AmbientCapabilities in [email protected]) > > - children (session services) run with Reg SMACK label (I added > support for DefaultSmackProcessLabel to user.conf, to avoid > modifications of all unit files)
sounds upstreamable. > > - 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? Quite frankly that should probably be the default behaviour. I'd probably merge a patch that unconditionally resets all caps passed to children of the --user manager even if the manager itself got some ambient caps passed. It might be a slight compat breakage, but I think it would be safer that way, as the service execution environment becomes more uniform then. Security credentials should be passed down to user services opt-in, not opt-out after all. Can you prep a patch for that and submit via github? Lennart -- Lennart Poettering, Berlin
