[lxc-devel] mount ro in guest change host filesystem to ro

Michael H. Warfield mhw at WittsEnd.com
Mon Sep 5 00:49:22 UTC 2011


On Sun, 2011-09-04 at 21:53 +0200, axel.schoener at gmx.de wrote: 
> Hi,
> 
> in my opinion it's never a bad idea to drop the sys_admin cap. except you 
> really need it.

It's been my personal experience that it's ALWAYS a bad experience to
drop sys_admin cap when you are doing a full system container.  You can
NOT even set your own host name for crying out loud!  You also can not
mount file images or set crypto keys.  If I was one of those container
owners, I would be asking "what the shit is this crap..."  Seriously...
Not an option.

> I' ve searched for some help because i'm using ubuntu only for 
> some study (normally gentoo).
> I found a little help here: http://qemu-buch.de/de/index.php/QEMU-KVM-
> Buch/_Anhang/_Weitere_Virtualisierer_und_Emulatoren/_LXC#Die_LXC-
> Konfigurationsdatei .
> 
> My guest is using these settings:
> lxc.cap.drop = sys_module mknod sys_admin
> 
> 
> My fstab for a ubuntu host look like this:
> # cat /var/lib/lxc/guest.temp01/fstab
> 
> proc    /var/lib/lxc/guest.temp01/rootfs/proc                           proc    
> nodev,noexec,nosuid                     0 0
> sysfs   /var/lib/lxc/guest.temp01/rootfs/sys                            sysfs 
> defaults                                  0 0
> 
> none    /var/lib/lxc/guest.temp01/rootfs/dev/shm                        tmpfs 
> mode=0644                                 0 0
> none    /var/lib/lxc/guest.temp01/rootfs/dev/pts                        devpts 
> defaults                                 0 0
> none    /var/lib/lxc/guest.temp01/rootfs/var/run                        tmpfs 
> defaults                                  0 0
> 
> none    /var/lib/lxc/guest.temp01/rootfs/sys/fs/fuse/connections        
> fusectl         optional                        0 0
> none    /var/lib/lxc/guest.temp01/rootfs/sys/kernel/debug               
> debugfs         optional                        0 0
> none    /var/lib/lxc/guest.temp01/rootfs/sys/kernel/security            
> securityfs      optional                        0 0
> 
> 
> Inside the container the lib/init/fstab has to be modified like this:
> # /lib/init/fstab: static file system information.
> #
> # These are the filesystems that are always mounted on boot, you can
> # override any of these by copying the appropriate line from this file into
> # /etc/fstab and tweaking it as you see fit.  See fstab(5).
> #
> # <file system> <mount point>             <type>          <options>                    
> <dump> <pass>
> /dev/root       /                         rootfs          defaults                          
> 0 1
> #none            /proc                     proc            nodev,noexec,nosuid               
> 0 0
> none            /proc/sys/fs/binfmt_misc  binfmt_misc     
> nodev,noexec,nosuid,optional      0 0
> none            /sys                      sysfs           nodev,noexec,nosuid               
> 0 0
> #none            /sys/fs/fuse/connections  fusectl         optional                          
> 0 0
> #none            /sys/kernel/debug         debugfs         optional                          
> 0 0
> #none            /sys/kernel/security      securityfs      optional                          
> 0 0
> none            /spu                      spufs           gid=spu,optional                  
> 0 0
> #none            /dev                      devtmpfs,tmpfs  mode=0755                         
> 0 0
> #none            /dev/pts                  devpts          
> noexec,nosuid,gid=tty,mode=0620   0 0
> none            /dev/shm                  tmpfs           nosuid,nodev                      
> 0 0
> none            /tmp                      none            defaults                          
> 0 0
> none            /var/run                  tmpfs           
> mode=0755,nosuid,showthrough      0 0
> #none            /var/lock                 tmpfs           
> nodev,noexec,nosuid,showthrough   0 0
> none            /lib/init/rw              tmpfs           
> mode=0755,nosuid,optional         0 0
> 
> 
> Regards, Axel Schöner
> 
> 
> 
> On Friday, 2. September 2011 11:51:55 Michael H. Warfield wrote:
> > On Fri, 2011-09-02 at 08:35 +0400, Michael Tokarev wrote:
> > > On 02.09.2011 00:46, Daniel Lezcano wrote:
> > > > On 09/01/2011 09:30 PM, Nico wrote:
> > > >> Hi,
> > > >> 
> > > >> I just wanted to give it a try again with lxc after one year,
> > > >> this is so bad same bugs are always here :
> > > >> 
> > > >> * you can do a "mount -o romount,ro /" inside container (reported
> > > >> since first times ... :( ),
> > > >> and host filesystem is remounted ro !!
> > > > 
> > > > Argh ! I still don't understand how that can happen with a
> > > > CLONE_NEWNS
> > > > and a pivot_root.
> > > > Do you have particular mount options on your host's rootfs ?
> > > 
> > > In order for guest remount to NOT influence host mount, you have to
> > > give -o bind option to mount inside guest.  If you don't specify
> > > MS_BIND with MS_REMOUNT, the remount applies to _host_ mountpoint,
> > > not guest.
> > 
> > Last time I recall playing with this was a couple of months ago and was
> > not the rootfs that was causing me headaches with random acts of
> > terrorism but the devpts file system mounted on /dev/pts.  When a
> > container would to a remount ro (the evil deed in the "halt" script that
> > was causing the problems) it would make ALL of the devpts mounts in the
> > host and in all of the other containers ro, and you were screwed till
> > you remounted it rw once again.  At the time, we played with things like
> > SLAVE, SHARED, and PRIVATE mounting with bind mounts and I had it
> > (mostly?) working for real file systems, like additional mounts, but
> > never did get it working for the pseudo file systems like devpts.
> > 
> > Now, you're saying, what we need to do is do a bind mount in the
> > container after the clone?  So lxc has to do this for every mount (not
> > just /) after cloning the container and before firing up init?  Do I
> > have that right?
> > 
> > I then see a potential problem right there (even assuming that works for
> > devpts - which I really hope it would).  What if someone in the
> > container mounts a new instantiation of devpts and then remounts it as
> > ro?  Will that propagate or no?
> > 
> > Blocking all mounts is not acceptable as there are too many things where
> > a container might want to do a mount on say iso images or something
> > similar.  Certainly the case if you are using this for development
> > systems (I work on the Network Security Toolkit run live iso from time
> > to time for instance).
> > 
> > Serge said something about needed to set up a test environment to
> > reproduce it but that was the last I heard from him on the subject back
> > then.  I wasn't sure if he was implying that it wasn't happening on an
> > Ubuntu host (I'm using Fedora) or what exactly.
> > 
> > > This has been discussed several times on irc.
> > 
> > Would have been nice if it had been echoed on the E-Mail channel.  I
> > don't look in on irc that often and E-Mail threads are better preserved,
> > specially when you've been disconnected for a while.  :-/
> > 
> > > /mjt
> > 
> > Regards,
> > Mike
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 

-- 
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-devel/attachments/20110904/2c8f6db7/attachment.pgp>


More information about the lxc-devel mailing list