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
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.

   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

Reply via email to