On 06/29/2012 12:14 PM, Serge Hallyn wrote:
> CAP_LAST_CAP in linux/capability.h doesn't always match what the kernel
> actually supports. If the kernel supports fewer capabilities, then a
> cap_get_flag for an unsupported capability returns -EINVAL.
>
> Recognize that, and don't fail when initia
CAP_LAST_CAP in linux/capability.h doesn't always match what the kernel
actually supports. If the kernel supports fewer capabilities, then a
cap_get_flag for an unsupported capability returns -EINVAL.
Recognize that, and don't fail when initializing capabilities when this
happens, rather accept t
Quoting Stéphane Graber (stgra...@ubuntu.com):
> On 06/29/2012 11:41 AM, Serge Hallyn wrote:
> > The following patch allows me to run lxc-execute -n p1 -- /bin/ls
> > as unprivileged user. I've pushed it to git://github.com/hallyn/lxc.git.
> > Thanks, Sam, for pointing this out.
> >
> > CAP_LAST_
On 06/29/2012 11:41 AM, Serge Hallyn wrote:
> The following patch allows me to run lxc-execute -n p1 -- /bin/ls
> as unprivileged user. I've pushed it to git://github.com/hallyn/lxc.git.
> Thanks, Sam, for pointing this out.
>
> CAP_LAST_CAP in linux/capability.h doesn't always match what the ker
The following patch allows me to run lxc-execute -n p1 -- /bin/ls
as unprivileged user. I've pushed it to git://github.com/hallyn/lxc.git.
Thanks, Sam, for pointing this out.
CAP_LAST_CAP in linux/capability.h doesn't always match what the kernel
actually supports. If the kernel supports fewer c
On 06/29/2012 11:32 AM, Stefan Schlesinger wrote:
>
> On Jun 29, 2012, at 4:19 PM, Jonathan Carter (highvoltage) wrote:
>> I would've put it on github or something but it's definitely going to be
>> abandoned for a python version that uses liblxc.
>>
>>> Would someone care to write a patch to imp
On Jun 29, 2012, at 4:19 PM, Jonathan Carter (highvoltage) wrote:
> I would've put it on github or something but it's definitely going to be
> abandoned for a python version that uses liblxc.
>
>> Would someone care to write a patch to implement ls in the api, against
>> lp:~ubuntu-lxc/ubuntu/qu
Ah, I see the problem. src/lxc/caps.c:lxc_caps_up() isn't detecting
supported capabilities correctly. When it gets -EINVAL for
cap_get_flags(), it should take that as a hint that the capability
is not supported by the kernel. Instead it exits with failure.
The reason you're not seing this on re
Hi Serge
On 29/06/2012 10:02, Serge Hallyn wrote:
> Good point. But note that lxc-ls is currently a script with no code in
> liblxc, so while we may get a version of the API with no ls defined, at
> least it won't have ls badly defined :)
>
>> IMHO the functionality of the three status commands c
Quoting Stefan Schlesinger (s...@ono.at):
>
> On Jun 28, 2012, at 5:35 PM, Ward, David - 0663 - MITLL wrote:
> > Just FYI, current git now allows you to list running containers
> > only with the '--active' flag to lxc-ls.
>
> The current version in Git also lists 'lost+found' as a virtual machine
On Jun 28, 2012, at 5:35 PM, Ward, David - 0663 - MITLL wrote:
> Just FYI, current git now allows you to list running containers
> only with the '--active' flag to lxc-ls.
The current version in Git also lists 'lost+found' as a virtual machine,
in case /var/lib/lxc is a separate filesystem (same
Quoting Jäkel, Guido (g.jae...@dnb.de):
> Dear Serge,
>
> >I don't know of a generic way this could be done in lxc.
>
> But it is desirable, right?
Well in a sense it's equivalent to the halting problem. A solution
to which is desirable but not achievable. We've had similar discussions
about s
Dear Serge,
>I don't know of a generic way this could be done in lxc.
But it is desirable, right?
> However, for your specific containers, you could redirect console to a file
> and have a script watch for a login prompt there?
One can think about a whole bunch of ways to reach the aim in a pr
13 matches
Mail list logo
