[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