> It's easy to blame something if you don't understand what
> you're blaming.
Yes, that's why I'm asking. To understand.
> 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),
make[1]: Entering directory `/home/libcap-2.19/libcap'
=> making cap_names.list.h from
/home/libcap-2.19/libcap/../libcap/include/linux/capability.h
perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[
\t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print
"{\"$tok\",$val},\n"; } }'
/home/libcap-2.19/libcap/../libcap/include/linux/capability.h | fgrep -v 0x >
cap_names.list.h
/bin/sh: line 1: perl: command not found
make[1]: *** [cap_names.list.h] Error 1
make[1]: Leaving directory `/home/libcap-2.19/libcap'
make: *** [all] Error 2
Care to guess again?
> and it is _required_ for lxc internally.
Currently, yes. But the way configure ends with this even afer you install
debian's libcap2:
Warning:
--------
The setcap binary was not found. This means the tools to set the
privilege for the lxc commands are not available, that's ok, but you
will need to run these commands as root or install libcap-2.
And the existence of HAVE_SYS_CAPABILITY_H in Config.h.in
implied to me that maybe it wasn't intentional, which is why I asked.
> No one forces _you_ to use capabilities.
Unless I want to use containers, you mean?
> It's a very
> simple construct unlike can be told from your description
> (you understanding is wrong, but this is not the point),
I agree it's not the point. I'd like to understand how I'm wrong, though.
The suid bit is pretty darn simple too. Securing a system with suid
executables isn't. Adding capabilities so that binaries try to drop
priviledges via setuid() and don't notice they can't (or any of the other
fun failures that can never happen until you retroactively change the
security model out from under the programmer in non-posix ways) is
one of those little perennial bits of fun that keeps on giving.
There's a theory among security types that a secure system is one that's
fully understood, and an insecure system is one that isn't. Thus "put all your
eggs in one basket and WATCH THAT BASKET" is sometimes a preferable
approach to painting over dry rot to create a multi-layered system no human
can quite understand the full ramifications of, in hopes the additional layers
will
contain the underlying misunderstandings. I've never quite understood why
if we can't get one security context right (where you're either on fire or not
on
fire, and you realize you're PLAYING WITH FIRE and do not let fire spread),
creating 2^32 different combinations is supposed to improve matters.
Is my reasoning defective because I don't agree with you? There is one true
opinion on this topic?
> 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.
Right, so the UID namespace thing where PID 1 isn't necessarily
using the host's UID 0 is useless then? My mistake.
> 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...
If you think every linux kernel programmer agrees on the color of the
sky I'm not sure we're talking abou the same group of people.
Does the fact the kernel uses RCU and spinlocks internally mean
userspace apps must use them, even if they want to be single-threaded?
I'm not following the logic here.
> I can only guess you're confusing capability system with
> something else which _is_ actually complex, but I can't
> guess what it is.
Translation: "We've hard-wired in the assumption you're using capabilities
from userspace into the design of lxc, and some of us might be a bit
defensive about it."
Ok.
Rob
------------------------------------------------------------------------------
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
