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

[Daniel J Walsh]

On 02/10/2016 11:16 AM, Lennart Poettering wrote:
> 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
>
BTW With the latest code/hooks we now have

/sys as readonly
/tmp and /run on tmpfs.
/etc/machine-id created to match containerid.
/var/log/journald/UUID mounted from the host so that journalctl -M UUID
will work.
Docker containers registered with machinectl.


These are the processes run after launching the systemd based container.

system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29042 ? 00:00:00 systemd
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29076 ? 00:00:00 systemd-journal
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29093 ? 00:00:00 dbus-daemon
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29094 ? 00:00:00 httpd
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29099 ? 00:00:00 httpd
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29100 ? 00:00:00 httpd
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29102 ? 00:00:00 httpd
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29104 ? 00:00:00 httpd
system_u:system_r:*svirt*_lxc_net_t:s0:c557,c563 29107 ? 00:00:00 httpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160210/a52af529/attachment.html>