Re: [RFC][PATCH] rbind across namespaces

[Mike Waychison <mikew@google.com>]

Miklos Szeredi wrote:
> (Sorry for replying in two parts, I missed this in the first reading)
> 
> 
>>>>walking mountpoints in userspace: 
>>>>http://marc.theaimsgroup.com/?l=linux-kernel&m=109875012510262&w=2
>>>
>>>
>>>Is this needed?  Userspace can find out mountpoints from /proc/mounts
>>>(or something similar for detached trees).
>>>
>>
>>With detached mountpoints (and especially with detached mountpoint
>>_trees_) it can become very difficult to assess which trees are which.
>>
>>Also, just like /proc/PID/fd/*, /proc/mounts is built according to
>>_current_'s root.  This only gives a skewed view of what is going on.
> 
> 
> I'm thinking of /proc/PID/fdinfo/FD/mounts or similar.
> 
> 
>>>>attaching mountpoints in userspace:
>>>>http://marc.theaimsgroup.com/?l=linux-fsdevel&m=109875063100111&w=2
>>>
>>>
>>>Again, bind from/to /proc/PID/fd/FD should work without any new
>>>interfaces.
>>
>>No..  It wouldn't.  Pathname resolution is doing everything according to
>>the ->readlink information provided by this magic proc files, again in
>>current's namespace.  If you care to hijack ->follow_link, prepare
>>yourself for a slew of corner cases.
> 
> 
> No need to hijack, it's already done.  Removing calls to
> proc_check_root() will allow access to different namespaces detached
> mounts, etc.  It's been tried and actually works.
> 

See previous message as why we don't want to allow this.

> What's more you don't even need /proc, just pass a file descriptor
> (with reference to mount in different namespace, etc.) to another
> process with SCM_RIGHTS, do fchrdir(fd), and then do mount --bind,
> etc.  This actually works with an unmodified kernel.

It shouldn't.  An unmodified kernel has check_mnt to keep you from doing 
this.

> 
> 
>>>>detaching mountpoints in userspace:
>>>>http://marc.theaimsgroup.com/?l=linux-kernel&m=109880051800963&w=2
>>>
>>>
>>>What's wrong with sys_umount()?
>>
>>sys_umount only works with paths in current's namespace. It doesn't
>>allow you to handle vfsmounts as primaries in userspace.
> 
> 
> But it does.  Again, either with fchdir() or /proc.
> 
> fchdir() has the drawback of only working on directories, and that a
> process has only one CWD.  The /proc approach has no such limitations.
> 

Again, check_mnt won't let this happen.

Another limitation is that manipulating mounts in another namespace 
breaks namespace->list locking..    Add that to a todo list if you still 
think this is a good idea.

Mike Waychison