Re: [PATCH] VFS autmounter support v2

Mike Waychison
2003-06-19T15:03:39Z

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