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
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 ef342abb22c1354b3523ce3c
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
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 t
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. libca
> 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
