[Lxc-users] systemd inside LXC

[Michael H. Warfield]

On Mon, 2012-10-22 at 18:37 -0400, Michael H. Warfield wrote:
> On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote:
> > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> > 
> > <Trimming some overhead we've seen enough of...>
> > 
> > > > > How about just a devtmpfs?  We actually now do this by default (as of very
> > > > > recently) in ubuntu by adding
> > > > 
> > > > > devtmpfs        dev          devtmpfs defaults 0 0
> > > > 
> > > > NO!  That's the problem!  That leads to the container connecting to the
> > > > hosts console and other devices and committing random acts of terrorism.
> 
> > > No, it shouldn't, because lxc sets up the console after doing the mounts.
> 
> > Damn, dude!  That worked!  That kludge rang da bell.  Of course, I also
> > discovered the boneheaded typo I had in attempting the tmpfs mount in
> > the process.  :-P  I now have a container running systemd up and running
> > with Fedora 17 in it.
> 
> > I'm not sure I'm totally happy with it.
> 
> > Because of doing the devtmpfs thing, the guest can immediately see
> > things like removable drives coming and going and might, presumably, be
> > able to mount them.  Not thrilled with that from a security standpoint.
> > Would also mean the guests could access things like my permanent
> > forensic CDs that are in the CD drives.  I guess that can be restricted
> > in the config but still makes me a bit uncomfortable that the guest has
> > complete visibility into the hosts dev system.

> Another downside.  Container does not shut down cleanly...

And another...

Container seems to hang if lxc-start is run in disconnected mode
(lxc-start -d -o {log}).  Starts up fine with a console that's connected
to pty's but not to a log it seems...

> init 0 inside the container...
> 
> In lxc-start -
> 
> Unmounting file systems.
> Could not remount as read-only /: Device or resource busy
> Not all file systems unmounted, 1 left.
> Detaching loop devices.
> Could not delete loopback /dev/loop7: Operation not permitted
> Could not delete loopback /dev/loop6: Operation not permitted
> Could not delete loopback /dev/loop5: Operation not permitted
> Could not delete loopback /dev/loop4: Operation not permitted
> Could not delete loopback /dev/loop3: Operation not permitted
> Could not delete loopback /dev/loop2: Operation not permitted
> Could not delete loopback /dev/loop1: Operation not permitted
> Could not delete loopback /dev/loop0: Operation not permitted
> Not all loop devices detached, 8 left.
> Cannot finalize remaining file systems and devices, giving up.
> Exiting container.
> lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/Alcove'
> 
> Not good.  The tasks file is empty but...  Can't get rid of it.
> "Operation not permitted".
> 
> Sigh...
> 
> Getting closer though.  Much closer.
> 
> > Another gotcha, albeit a much more minor one...  When systemd drops into
> > this mode, you no longer have vty consoles available so lxc-console
> > won't work.  That's actually on their page.
> 
> > I remember seeing this:
> > 
> > -- 
> > If systemd detects it is run in a container it will spawn a single shell
> > on /dev/console, and not care about VTs or multiple gettys on VTs
> > -- 
> > 
> > Suboptimal but a small price to pay I suppose.
> > 
> > > -serge
> > 
> > Regards,
> > Mike
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20121022/7488b77d/attachment.pgp>