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 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 > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
