Quoting Christian Seiler (christ...@iwakd.de): > Hi again, > > >> Extending lxc-attach would also be fine by me - is anybody already > >> working on this? If not, I'd be willing to do that. > > > > It's on the todo list at the moment, I don't believe anyone is > > actively working on it at the moment. > > > > So if you want to do it, it'd be much appreciated. > > Ok, I'll get back to you on that. > > > I believe the idea was to keep the same syntax as lxc-unshare for > > lxc-attach. Essentially introduce a -s flag accepting an ORed list of > > namespaces. > > Yes, sounds reasonable to me. Just one question: I've actually taken a > peek at iproute2's implementation now that you mentioned it and they > actually do two things in ip netns exec: > > - they setns() to the new namespace > - they unshare the mount namespace and remount /sys - apparently, in > contrast to /proc, which depends on the current process's context, > /sys depends on the context of the process mounting it
Both actually depend on the context of the process mounting it. If you do "lxc-unshare -s PID /bin/bash" and then do "echo $$" and "ls /proc", you'll see proc is still the old proc. Both proc and sys need to be remounted from in the new namespace to reflect the new namespace's contents. > So for lxc-attach without mount namespaces but with network namespaces, > should we do the same? (i.e. catch that case) Or should we just ignore I think we should let users do this themselves, but warn about it in the lxc-attach manpage. > /sys? Do any non-shell-script utilities actually use it? I am under the > impression that any network interface information is also available via > netlink or similar, and that all "real" tools use that, which does take > into account process context. (One could even argue that /sys should - > just as /proc does - reflect the current namespace for relevant things > and that this is a bug/missing feature in the kernel.) Thoughts? > > > Currently only ipc, net and uts are usable on a standard kernel, > > patches for the remaining ones and the user namespace are currently > > on lkml with some of them in linux-next. > > About only ipc, net and uts being usable, I know about that, I'm > currently using the patches under > <http://lxc.sourceforge.net/patches/linux/3.0.0/3.0.0-lxc1/patches/> > (slightly modified to apply against 3.2) to be able to properly use > lxc-attach. I'm glad to hear that they are on their way into the kernel. > > 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
