I come from an embedded background so I ask why everything is actually needed. Currently I'm setting up an openvz test environment and the first chroot I tried to use was a uClibc+busybox one I had lying around, and building lxc natively in that environment wanted me to install libcap (which is so obscure that googling for it thinks you mean libpcap), and which required I first build and install perl as one of its build prerequisites.
I've since moved on to a debootstrap sid, but my question still stands because containers have their own PID 1 and their own UID namespace, which means they have local root. Tangling in capabilities is like tangling in selinux, it seems to me that the more heavyweight the solution is from an administrative standpoint the less likely casual users are to pick it up and use it. Do you really want to limit the entire potential audience of containers to a subset of the people who think capabilities are a good idea? Is there a strong reason to _exclude_ them? What is this extra complexity actually needed for? Rob ________________________________________ From: Michael Tokarev [...@tls.msk.ru] Sent: Friday, December 17, 2010 3:12 AM To: Rob Landley Cc: lxc-devel@lists.sourceforge.net Subject: Re: [lxc-devel] Building without libcap2? 17.12.2010 05:48, Rob Landley wrote: > Is there any way to tell lxc that I'll run it as root if I want root access, > and not to fiddle with capabilities? (If there's a ./configure option for > this, I haven't found it...) What problem you're trying to solve? /mjt ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
