[systemd-devel] Question about the killing spree during the transition from the initrd to the root file system.

[Demi Marie Obenour]

On Tue, Jul 09, 2024 at 12:13:38PM +0200, Lennart Poettering wrote:
> On Mo, 08.07.24 15:57, Demi Marie Obenour (demi at invisiblethingslab.com) wrote:
> 
> > On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote:
> > > On Do, 04.07.24 12:44, Demi Marie Obenour (demi at invisiblethingslab.com) wrote:
> > >
> > > > > No, these belong to your process, systemd couldn't really reach into
> > > > > your processes to close them, even if it wanted to.
> > > > >
> > > > > But do note that any files you keep open or mapped at the moment of transition
> > > > > will remain pinned in memory, and cannot be released by the
> > > > > kernel. this means that even though during the tmpfs→host transition
> > > > > we generally destory the initrd's tmpfs' contents, the stuff you keep
> > > > > pinned will stick around.
> > > > >
> > > > > Generally, only special purpose software should be left around that
> > > > > way, if it is carefully written to handle this. For example it is not
> > > > > allowed to dlopen() anything (and hence no NSS either! No
> > > > > gethostbyname() or getpwnam() or so), because you'd otherwise end up
> > > > > with a weird mix of match of shared libs from the initrd and the host.
> > > >
> > > > If one does need to e.g. do DNS lookups in such a process, what is the
> > > > best way to do it?
> > >
> > > Well, simply don't write programs like that, of course.
> > >
> > > But if you really feel you must:
> > >
> > > If you need DNS, then do the lookups via your own statically linked
> > > DNS lib maybe?
> > >
> > > You could talk to resolved's varlink or D-Bus interfaces too, but I
> > > find this a bit icky, since you'll end up consuming services provided
> > > by the OS on the root fs, while you should instead provide services to
> > > that OS, but not consume them.
> > >
> > > If you want user/group name resolution: these are generally a resource
> > > manager by the host OS, hence you almos certainly are doing things
> > > wrong if you want to resolve them from your initrd service. You could
> > > talk to userdbd of course, via Varlink IPC, but the same applies as
> > > above: it's a bit icky if you consume services provided by the OS, if
> > > you are such a low-level daemon that must survive from initrd into
> > > host.
> > >
> > > In many ways: if you run like this you should consider yourself
> > > conceptually closer to kernelspace than to userspace. And hence, the
> > > same way as kernelspace generally doesn't resolve users or hostnames
> > > you shouldn't really either.
> >
> > What is the most common use-case for such daemons?  I thought that it
> > was for network-attached root filesystems.  Such a daemon might well
> > need to do DNS lookups.
> 
> As I said above, if you really can't avoid DNS, then do DNS, but do it
> yourself, i.e. add your own DNS client, and do not use OS services for
> this. i.e. no NSS that involves dlopen() on modules from the rootfs or
> talks to IPC services of the OS.

Would talking to systemd-resolved from the host OS do any damage?  I
agree that it isn't elegant, but neither is having completely separate
DNS configuration that can and will get out of sync.  At a minimum, is
it okay to listen for changes to systemd-resolved's configuration, so
that the daemon's own resolver can stay in sync?

I know that needing a call to systemd-resolved to e.g. resolve a page
fault from systemd-resolved itself will deadlock.  I'm assuming that the
daemon is designed so that this never happens.  And yes, it might be
better to go through a proxy process from the root FS in this case.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240709/61979b3e/attachment.sig>