Quoting Christian Seiler (christ...@iwakd.de): > Hi, > > >> - 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. > > Actually, it's even more complicated than that. Try the following: > > lxc-unshare -s NETWORK -- cat /proc/self/net/dev > > I did a few simple tests and found the following: > > Network namespaces: > /proc/$pid/net Context of process $pid > /sys/class/net etc. Context of process mounting /sys > PID namespaces: > /proc Context of process mounting /proc > Mount namespaces: > /proc/$pid/mountinfo Context of process $pid > > So - due to the /proc/self logic - for network namespaces, one only
Right, so long as you are not also doing '-s PID|NETWORK' then /proc/self will work. However if you add PID, then /proc/self will not work (will point to the wrong task or to nowhere). To be clear it's not the /proc/self logic, it's the logic for all /proc/$pid directories. Those contents reflect per-process values. > needs to remount /sys, for PID namespaces, only /proc; and for mount > namespaces we don't really care since if we attach to a mount namespace > that belongs to a container, the corresponding file systems we see are > already mounted in the correct context. > > >> 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. > > I agree it may be wise not to do too much as a default in order not to > confuse users, however, I really would like lxc-attach to be able to > handle this stuff on its own if needed. > > Suggestion: > > 1) Default behavior: Just attach to specified namespaces. > 2) Additional command line flag -R, (or something else, if you prefer) > that does the following: > > a) If the process is to be attached to either NETWORK or PID > namespaces > -and- > b) it is NOT to be attached to the MOUNT namespace > > then *additionally* unshare (not attach) MOUNT namespace, > remount /sys and /proc. That sounds ok to me, so long as it gets no further involved than that. A good default. > Ignore the flag if those conditions are not met. > > Because if we leave that completely to the user, one really has to do > something along the lines of > > lxc-attach -n container -s NETWORK -- \ > lxc-unshare -s MOUNT -- /bin/bash -c \ > "umount /sys ; mount -t sysfs none /sys ; \ > umount /proc ; mount -t proc none /proc ; \ > /some/complicated/command/that/uses//sys" > > instead of simply > > lxc-attach -n container -R -s NETWORK -- \ > /some/complicated/command/that/uses//sys > > The first seems like too much of a mouthful to me. Thoughts? > > Other than this issue and the man page, I have a patch for lxc-attach > ready; as soon as I get to update the man page I'll post it to the list. > (The /proc and /sys stuff can be added later IMHO.) > > 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
