[lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces

Serge Hallyn serge.hallyn at canonical.com
Tue May 22 15:18:29 UTC 2012


Quoting Christian Seiler (christian at 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 question.
> >
> >So I think we should do your point 1, but not your point 2.  I'm
> >still
> >not happy about special casing user ns in the code.  What will happen
> >when we get devices namespaces and most people, but not all, have
> >/proc/self/ns/user?  More hard-coded exceptions?
> >
> >I don't have an answer right now, just not happy with any of the
> >ones I can think of.  (Will keep thinking)
> 
> 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 which were started without
any command line changes.  But even with a persistent container with
no network section, I could add a network section on the lxc-start
command line with '-s' arguments, making the set of cloned namespaces
different from what you'd expect from the config file.  So there is
no good way I can think of, generally, to get that bitmask of CLONE_*
flags used for starting the container.

We could start storing that in a lxc-generated state file.

>  - no -s paramter for lxc-attach: attach to all namespaces found in
>    the bitmask retrieved via the command interface (and fail if
>    kernel doesn't support it)
>  - user supplied -s parameter: try only those and fail if that doesn't
>    work
> 
> Then nothing would be hard-coded and it'd be completely future-proof.
> 
> Thoughts?
> 
> Regards,
> Christian
> 




More information about the lxc-devel mailing list