On 05/22/2012 05:58 PM, Christian Seiler wrote:
> Hi Serge,
>
> What about if we update the command interface to add an additional
> command along the lines of LXC_COMMAND_GET_NSFLAGS or similar,
>>> which
> returns the bitmask of CLONE_* used for starting the container?
>>> Then
>
Hi Serge,
>> >>What about if we update the command interface to add an additional
>> >>command along the lines of LXC_COMMAND_GET_NSFLAGS or similar,
>> which
>> >>returns the bitmask of CLONE_* used for starting the container?
>> Then
>> >>we would have the logic:
>> >
>> >That works fine for p
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> >>What about if we update the command interface to add an additional
> >>command along the lines of LXC_COMMAND_GET_NSFLAGS or similar, which
> >>returns the bitmask of CLONE_* used for starting the container? Then
> >>we would have th
Hi Serge,
>> What about if we update the command interface to add an additional
>> command along the lines of LXC_COMMAND_GET_NSFLAGS or similar, which
>> returns the bitmask of CLONE_* used for starting the container? Then
>> we would have the logic:
>
> That works fine for persistent containers
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> >That sounds good, but then to do it right the "which namespaces were
> >unshared by the container" shouldn't be hardcoded in. Unfortunately,
> >without the /proc/self/ns/ links there's no way to tell, so we can't
> >answer your quest
Hi Serge,
> That sounds good, but then to do it right the "which namespaces were
> unshared by the container" shouldn't be hardcoded in. Unfortunately,
> without the /proc/self/ns/ links there's no way to tell, so we can't
> answer your question.
>
> So I think we should do your point 1, but not
Serge Hallyn writes:
> Quoting Christian Seiler (christ...@iwakd.de):
>> This patch adds the -s/--namespaces option to lxc-attach that works
>> analogously to lxc-unshare, allowing the user to select the namespaces the
>> process should be attached to.
>>
>> User namespaces are supported, under
Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> >Note that for now the same thing will happen with pid. I don't think
> >CLONE_NEWUSER needs to be special cased. Likewise, someone may want
> >to use this lxc on an older kernel without any setns support at all.
>
> I'm not sure th
Hi Serge,
> Note that for now the same thing will happen with pid. I don't think
> CLONE_NEWUSER needs to be special cased. Likewise, someone may want
> to use this lxc on an older kernel without any setns support at all.
I'm not sure this is wise: Currently, kernel 3.0 supports all
namespaces
Quoting Christian Seiler (christ...@iwakd.de):
> This patch adds the -s/--namespaces option to lxc-attach that works
> analogously to lxc-unshare, allowing the user to select the namespaces the
> process should be attached to.
>
> User namespaces are supported, under the assumption that the file i
This patch adds the -s/--namespaces option to lxc-attach that works
analogously to lxc-unshare, allowing the user to select the namespaces the
process should be attached to.
User namespaces are supported, under the assumption that the file in
/proc/pid/ns will be called 'usr'. Currently, user name
11 matches
Mail list logo
