[systemd-devel] I want to run systemd inside of a locked down base docker container

[Lennart Poettering]

On Wed, 10.02.16 10:56, Daniel J Walsh (dwalsh at redhat.com) wrote:

> On Fedora I see a few services starting up and failing when I run
> systemd, I have been able  to disable these
> by executing.
> 
> RUN systemctl disable sysinit.target remote-fs.target
> systemd-remount-fs;\

sysinit.target and systemd-remount-fs.service are static units; they
cannot be enabled via "systemctl enable" or disabled via "systemctl
disable". That part should be a NOP and should not have any effect;
you can drop it.

remote-fs.target has no value either, unless there actually are NFS
mounts listed in /etc/fstab. I am pretty sure there aren't any for in
your container, are there? Hence, this really sounds like something
you can drop too, without any change in behaviour.

>     systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service
> systemd-udev-settle.service systemd-udev-trigger.service
> systemd-udevd.service systemd-udevd-control.socket
> systemd-udevd-kernel.socket; \

The systemd-firstboot service should have no effect unless you
actually boot with an empty /etc (or more accuratily: unless you
actually boot with an /etc that lacks /etc/machine-id) . Note that it
carries a condition ConditionFirstBoot=yes which makes sure that it
isn't even executed in normal cases. 

Masking all the udev stuff is pretty pointless too. These services are
conditioned out in containers too anyway. There's really no need to
mask them out. More specifically, they contain
ConditionPathIsReadWrite=/sys, i.e. are skipped if /sys is read-only,
which is the way how container managers should set up /sys (it's a big
security hole to allow containers write access to /sys). My
recommendation would be to make sure you container manager implements
these recommendations:

https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/

If your container manager follows these guidelines (of which the /sys
being read-only thing is one), then there should be no special hacks
necessary in systemd, as it should just work, and detect the slight
semantica changes of containers correctly and avoid them cleanly.

>     rm -f /lib/systemd/system/multi-user.target.wants/systemd*
>     /lib/systemd/system/multi-user.target.wants/getty*;\

What's the rationale for this? First of all, the getty stuff appears
entirely unnecessary as getty at .service (which is the only thing
generally linked from gettys.target these days) contains
ConditionPathExists=/dev/tty0 which means it's already skipped when
run on systems lacking a VC (such as containers).

And the other services you are removing here: what's the point? they
aren't really optional, that's why they are linked from /usr/lib,
rather than subject to systemctl enable/disable...

>     sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* 

Why would this matter?

> Could someone look at these and tell me if I went too far.  I would like to get these commands as the default for systemd in the base
> RHEL/Fedora and Centos containers.

I don't follow at all. 

None of this is necessary. systemd works fine in containers as long as
the container manager follows these guidelines:

https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/

nspawn implements all of this, and docker really should too...

Lennart

-- 
Lennart Poettering, Red Hat