17.12.2010 23:44, Rob Landley wrote: > 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?
It's easy to blame something if you don't understand what you're blaming. Capabilities (libcap2) is a tiny library (on my i386 userspace it's just a 13Kb shared object), it has _no_ external dependencies whatsoever - neither at build nor at run time (it does not use perl for one), and it is _required_ for lxc internally. No one forces _you_ to use capabilities. It's a very simple construct unlike can be told from your description (you understanding is wrong, but this is not the point), but it is used by lxc tools internally. For example, you don't want a container to be able to shut down your host machine by executing sys_reboot syscall - this is ensured by dropping CAP_SYS_BOOT when entering container. Note that every permission check in linux kernel is built based on capabilities, so at least every linux kernel programmer thinks capabilities are a good thing... I can only guess you're confusing capability system with something else which _is_ actually complex, but I can't guess what it is. /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
