Re: [PATCH] VFS autmounter support v2

[Mike Waychison <michael.waychison@sun.com>]

David Howells wrote:

>>>Then have a daemon that can take a request to mount and then reply with
>>>the mount parameters, allowing the trap fs to obtain a vfsmount via
>>>do_kern_mount(). I would make the trap fs supply the daemon with an fd
>>>attached to the trap rootdir to act as a token representing the request
>>>(and controlling its lifetime).
>>>
>>>      
>>>
>>You would have to go this route.  I think Al's opinion in this is that 
>>your original proposal allows arbitrary dentry's in the tree to act as 
>>traps.  As such, there is no way for a derived namespace to manipulate 
>>that trap at all.
>>    
>>
>
>  
>
>>By implying that the trap is installed via mount says you are now proposing
>>that every trap is represented by its own superblock.
>>    
>>
>
>This is more or less what Al suggested, except that he suggested "traps" are
>special vfsmounts that don't have superblocks, dentries, and inodes.
>

Introducing special trap vfsmounts w/o super_blocks means we can no 
longer have arbitrary actions on those traps.  AFS wants to define what 
happens in kernelspace, autofs wants to define it in userspace.  Last I 
checked, vfsmount doesn't have an ops structure.

> 
>  
>
>>You're new proposal is exactly what I have been working on, autofs 
>>direct mountpoints using the less intrusive follow_link magic Anvin has 
>>mentioned on a previous thread both here and on autofs@vger.
>>
>>The one problem with this solution is the following breaks:
>>
>># installtrap /foo host:/export/foo
>><userspace daemon listens for requests to mount>
>># newnssh
>>newnssh # cd /foo
>>
>>Oops, the daemon started from the initial namespace doesn't have access 
>>to the namespace in my second shell.
>>    
>>
>
>Yes. You can see that happening now with autofs and amd. However it does work
>with my suggestion because the "automounter" code just returns a namespace
>independent vfsmount, which the VFS can then bind into the appropriate
>namespace and the appropriate place.
>

This only works for mounts performed in kernel space.  It doesn't lend 
itself to performing mounts in userspace and would force autofs to 
re-implement mount(1) parsing/struct packing in kernelspace.  Definitely 
not a good solution.

>
>  
>
>>The most reasonable way I can see to cope with this is to allow 
>>CAP_SYS_ADMIN processes the ability to change namespaces.  Eg, the 
>>daemon can be told which pid triggered the trap on /foo, 
>>open(/proc/<pid>/mounts) and perform a ioctl(IOC_USENAMESPACE) on it.
>>
>>What do you guys think?
>>    
>>
>
>I think a better way is for the kernel to pass the daemon a file descriptor
>attached to the mount point. This would then act as a token representing the
>request, and as such it automatically includes the mount point info (struct
>file has vfsmount/dentry pointers) and can also be used to manage the lifetime
>of the request.
>
>I'd then make there be either a "mount" ioctl/fcntl on that fd that uses the
>info stored on the struct file, or perhaps provide an "fmount" syscall (but
>you have to be careful - otherwise someone can use an arbitrary
>cross-namespace fd to mangle some other namespace).
>  
>
A mount ioctl on the fd is probably a good idea:
    - it would require modifying mount(1) so that you can have it use 
the fd ioctl in lieu of sys_(old)mount.
    - he have to ask ourselves, does this logic really belong in vfs? or 
is it better placed in a filesystem-independent implementation.

I'm still partial to the idea that a usenamespace ioctl on 
/proc/<pid>/mounts is a cleaner solution in the long run, both for 
automounting as well as for administration tools.

Mike Waychison