[lxc-devel] Building without libcap2?

Michael Tokarev mjt at tls.msk.ru
Fri Dec 17 21:12:08 UTC 2010


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




More information about the lxc-devel mailing list