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
[lxc-devel] [GIT] lxc branch, master, updated. fd4f5a5688e511554ddd1f3fdbf1f05264b5b483
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via fd4f5a5688e511554ddd1f3fdbf1f05264b5b483 (commit) via ef342abb22c1354b3523ce3c46e613e13ab79399 (commit) via 36b862992a8e685534774a59793fb5c5bad46fae (commit) via b234e44fdfb03ebb29f9bcb121d83e25b5a49800 (commit) via 7c282e3cf4f46ee2e95589367904732f06c86af6 (commit) via 4839ec2994ddf104fd135cdca9a48bebcd6e55f4 (commit) via 59760f5d0f441c4d5ce165498abadcbd7409e9bb (commit) from 968fbd36057db3132c68a63700e42929e5df5e2d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit fd4f5a5688e511554ddd1f3fdbf1f05264b5b483 Author: Daniel Lezcano Date: Fri Dec 17 11:43:37 2010 +0100 use clone_children cgroup's flag If the ns_cgroup does not exist, we use the clone_children feature. Everytime a cgroup is created, we set this compatibility flag and we create the cgroup manually and add the child task to the cgroup. Signed-off-by: Daniel Lezcano commit ef342abb22c1354b3523ce3c46e613e13ab79399 Author: Daniel Lezcano Date: Fri Dec 17 11:43:37 2010 +0100 Move common code to lxc_cgroup_create For both the ns_cgroup and the usual cgroup creation, we have to check if a previous does not exist and remove it if it is empty. Signed-off-by: Daniel Lezcano commit 36b862992a8e685534774a59793fb5c5bad46fae Author: Daniel Lezcano Date: Fri Dec 17 11:43:37 2010 +0100 encapsulate the ns_cgroup Create a single API to create a cgroup which will switch to the old ns_cgroup automatically. Signed-off-by: Daniel Lezcano commit b234e44fdfb03ebb29f9bcb121d83e25b5a49800 Author: Daniel Lezcano Date: Fri Dec 17 11:43:37 2010 +0100 Change nscgroup interface Prepare the nscgroup to be converted to the clone_children changes. Signed-off-by: Daniel Lezcano commit 7c282e3cf4f46ee2e95589367904732f06c86af6 Author: Daniel Lezcano Date: Fri Dec 17 11:43:37 2010 +0100 Remove unused nscgroup field This field is unused. Signed-off-by: Daniel Lezcano commit 4839ec2994ddf104fd135cdca9a48bebcd6e55f4 Author: Daniel Lezcano Date: Fri Dec 17 11:43:36 2010 +0100 remove duplicate cgroup header Signed-off-by: Daniel Lezcano commit 59760f5d0f441c4d5ce165498abadcbd7409e9bb Author: Michael Tokarev Date: Fri Dec 17 11:43:36 2010 +0100 Make mount paths relative to rootfs Why not chdir into the root of container right when the root filesystem is (bind-)mounted, and let all mount entries to be relative to the container root? Even more, to warn if lxc.mount[.entry] contains absolute path for the destination directory (or a variation of this, absolute and does not start with container root mount point)? This way, all mounts will look much more sane, and it will be much easier to move/clone containers - by changing only lxc.rootfs. I do it this way locally since the beginning, by chdir'ing to the proper directory (rootfs) before running lxc-start (in a startup script), but this is now broken in 0.7.3 which bind-mounts rootfs somewhere in /usr/lib/lxc. Signed-off-by: Michael Tokarev Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/cgroup.c | 147 + src/lxc/cgroup.h |4 +- src/lxc/conf.c| 45 --- src/lxc/lxc_unshare.c |2 +- src/lxc/start.c |5 +- src/lxc/start.h |1 - 6 files changed, 154 insertions(+), 50 deletions(-) hooks/post-receive -- lxc -- 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
Re: [lxc-devel] Building without libcap2?
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
Re: [lxc-devel] Building without libcap2?
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
Re: [lxc-devel] Building without libcap2?
18.12.2010 00:12, Michael Tokarev wrote: [] > 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 this is, in turn, incorrect. libcap2 does use perl at build time, in order to create list of currently defined capabilities from linux/capability.h. Two trivial inline perl scripts which are not architecture-dependent. /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
Re: [lxc-devel] Building without libcap2?
> 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
