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.
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.
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?
Mike Waychison
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/