[Lxc-users] systemd inside LXC

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> Serge,
> 
> I'm going to top post here simply because this is going to go off in a
> different direction and bringing in an old thread but it is related...
> 
> Back on February 14 you responded to a message about Fedora 16 in a
> container, which is something I've been trying to do and I had run into
> that posters problems.  You responded with this:
> 
> Subject: Re: [Lxc-users] fedora 16 under lxc
> 
> On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote:
> > Quoting Ramez Hanna (rhanna at informatiq.org):
> 
> > > now all my efforts have not succeedd to get getty on tty1 to start
> > > unmasking udev did something different
> > > it created all the /dev devices
> > > and made getty start but it started on the hosts's tty not on the container's
> > > could someone shed some light here?
> > 
> > Blind guess:
> > 
> > lxc-start creates some ptys and bind mounts them onto the guest's
> > /dev/{console,tty{1,2,3,4}}.  It sounds like fedora's init is mounting
> > over the /dev set up by lxc causing a new /dev/tty to be created as
> > chardev 4:{1-4}.  Devices namespaces would help this.  We're hoping to
> > discuss design for those at next UDS, but those will come after user
> > namespaces.  In the mean time, you'll need to make sure that the guest
> > does not mount over /dev, and does not remount /dev/pts.
> > 
> > -serge
> 
> That got me thinking and started into looking deeper into systemd, which
> Fedora 16 and above uses and why it may be related here.  I've made
> Fedora 16 work in the past by installing upstart and disabling systemd
> but that really becomes impractical in Fedora 17 because they're
> including so few of the compatibility scripts.  Yes, you are right, the
> Fedora's init (systemd) is mounting something on /dev like this:
> 
> devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=1784160k,nr_inodes=446040,mode=755)
> 
> This is very bad for the reasons you pointed out in Feb.  Looking at the
> source code for systemd, this is hard coded into the binary and is not
> configurable.
> 
> systemd-37/src/mount-setup.c:
> -- 
> /* The first three entries we might need before SELinux is up. The
>  * other ones we can delay until SELinux is loaded. */
> #define N_EARLY_MOUNT 3
> 
> static const MountPoint mount_table[] = {
>         { "proc",     "/proc",                  "proc",     NULL,                MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
>         { "sysfs",    "/sys",                   "sysfs",    NULL,                MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
>         { "devtmpfs", "/dev",                   "devtmpfs", "mode=755",          MS_NOSUID,                    true },
>         { "tmpfs",    "/dev/shm",               "tmpfs",    "mode=1777",         MS_NOSUID|MS_NODEV,           true },
>         { "devpts",   "/dev/pts",               "devpts",   "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false },
>         { "tmpfs",    "/run",                   "tmpfs",    "mode=755",          MS_NOSUID|MS_NODEV, true },
>         { "tmpfs",    "/sys/fs/cgroup",         "tmpfs",    "mode=755",          MS_NOSUID|MS_NOEXEC|MS_NODEV, false },
>         { "cgroup",   "/sys/fs/cgroup/systemd", "cgroup",   "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, false },
> };
> -- 
> 
> Short of building a custom systemd, I don't know how to fix that problem
> and I suspect this OP is going to run into this same thing (container
> taking over host's console) and might explain some of what he's seeing.
> Several of these look like they could cause problems (like /dev/pts in
> there).  I've really reached an impasse at getting systemd (at least
> Fedora 16 and 17) to work in a container without screwing up the host.
> Prohibiting mounts entirely in the container might work but I suspect
> (having read some systemd error messages) systemd is going to have some
> serious heartburn there.
> 
> Thoughts?

IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
container should work, i.e. systemd was not going to fail as a result.

-serge