Bug#778581: systemd install breaks chroot jail and compromises guest system

[Martin Pitt]

Hey Wolfgang,

Wolfgang Rosner [2015-02-17  1:13 +0100]:
> - <server$> chroot /path/to/client-root /bin/bash
> - CHR#>  apt-get install <lots of stuff w/o problems>
> - CHR#>  apt-get install systemd

FTR, I install the systemd package into chroots all the time to test
stuff, this is supposed to work fine.

> The last command leads to some error message (I can't remember)

If you can reproduce this, seeing the error message would be useful.

> Then, after googling, I run something like dpkg -a (still in the chrooted shell)

That doesn't exist. Perhaps sudo dpkg-reconfigure --all? That would
indicate that systemd in the chroot failed to install indeed. Again
this needs more information, like the actual error message (it's
supposed to work, and does here).

However, my chroots have a policy-rc.d which avoids the startup of
daemons from postinst scripts, as this conceptually doesn't work in
chroots and *would* mess up the host indeed. Is that the case for you?
(Note that mk-sbuild etc. set up policy-rc.d automatically, but I
figure that's not what you did). See man invoke-rc.d.

> 
> root at cruncher:/cluster/tftp/active/pxelinux.cfg# dpkg --list | grep systemd
> ii  libpam-systemd:amd64                  215-8                                  amd64        system and service manager - PAM module
> ii  libsystemd-login0:amd64               44-11+deb7u4                           amd64        systemd login utility library
> ii  libsystemd0:amd64                     215-8                                  amd64        systemd utility library
> ii  systemd                               215-8                                  amd64        system and service manager
> ii  systemd-shim                          9-1                                    amd64        shim for systemd
> 
> root at cruncher:/cluster/tftp/active/pxelinux.cfg# grep systemd /var/log/apt/history.log
> 
> ..... is EMPTY ....
> 
> So I think systemd got installed accidentially by breaking the chroot.

Or perhaps it got installed by default when you set up this system?
That's much more likely, given that it's a required component on a
desktop.

> I also think that my mount list is weird and contains both systemd and sysv-init mounts:
> 
> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
> udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=2036655,mode=755)
> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1637124k,mode=755)
> /dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
> tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=9524120k)
> /dev/sda4 on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
> /dev/sdb2 on /ssd type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
> rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
> binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
> cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k)
> configfs on /sys/kernel/config type configfs (rw,relatime)
> nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
> systemd on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/x86_64-linux-gnu/systemd-shim-cgroup-release-agent,name=systemd)
> tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=1637124k,mode=700)
> tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1637124k,mode=700,uid=1000,gid=1000)

I don't see anything weird here. That's all expected for a desktop
which is running systemd-shim with sysvinit.

> However, the system behaviour seems OK as far as I can tell.
> 
> How can I get rid of the situation?

I don't know at all what the error actually is here; so far the
"situation" appears to be "all normal and expected" on your host, and
you just need to provide more information about the install failure in
the chroot. The most likely explanation is that your chroot doesn't
have a policy-rc.d.

> May be it is difficult / impossible to install such fundamental
> stuff like systemd into a chrooted debootstrap.

Should work fine with policy-rc.d, and installing any service into a
chroot without it is doomed to cause trouble. :-)

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)