On Sun, 2011-09-04 at 21:53 +0200, axel.schoe...@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
