[systemd-devel] loose thoughts around portable services

[Lennart Poettering]

On Mi, 20.10.21 16:01, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> > That said: systemd's nss-systemd NSS module can nowadays (v249) read
> > user definitions from drop-in JSON fragments in
> > /run/host/userdb/. This is is used by nspawn's --bind-user= feature to
> > make a host user easily available in a container, with group info,
> > password and so on. My plan was to also make use of this in the unit
> > executor, i.e. so that whenever RootDirectory=/RootImage= are used the
> > service manager places such minimal user info for the selected user
> > there, so that the user is perfectly resolvable inside the service
> > too. This is particularly relevant for DynamicUser=1 services. I
> > haven't come around actually implementing that though. Given
> > nss-systemd is enabled in most bigger distro's nssswitch.conf file
> > these days I think this is a really nice approach to propagate user
> > databases like that.
> >
>
> Why don't we also make the varlink user API available to most of the
> profiles? This way sandboxed service doesn't need any of the nss conf and
> libraries if they don't want to. Most profiles allow dbus communication. I
> guess in a similar thought, most system services should be able to do a
> user lookup in a modern way.

I sympathize with the idea, but I am not entirely sure this is
desirable to do this 1:1, as this means we'd leak a ton of stuff that
might only make sense on the host into something that is supposed to
be an isolated container. i.e. home dir info and things like
that. shell paths and so on.

Maybe we can find a middle ground on this though. i.e. we could make
systemd-userdb.service listen on a new varlink service socket that
provides the host's database to sandboxed environments in a restricted
form, i.e. with basically all records dumbed down to just contain
uid/gid/name info and nothing else.

We'd then update the portabled profiles that do not use PrivateUsers=
to bind mount that one socket, so that they get the full db,
dynamically.

I kinda like the idea.

> We could implement our own profiles without needing nesting but we believe
> it is beneficial to collaborate on profiles upstream and have common
> additions to upstream profiles with nesting other profiles. If we get to it
> before other people, we would really like to contribute and send a patch on
> this.

A patch adding .d/ style drop-ins for profiles would make a ton of
sense. Happy to take that.

Lennart

--
Lennart Poettering, Berlin