Hi,
in my opinion it's never a bad idea to drop the sys_admin cap. except you
really need it. 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
