Re: [PATCH] Add MS_BIND_FLAGS mount flag

[Trond Myklebust]

On Thu, 2008-02-14 at 18:39 +0100, Miklos Szeredi wrote:
> > > And I'm not against doing it with the "at*" variants, as Trond
> > > suggested.
> > 
> > If you're going to change the syscall, then you should ensure that it
> > solves _all_ the problems that are known at this time. Ignoring the
> > automounter issue is just going to force us to redo the syscall in a
> > couple of months...
> 
> Sure.
> 
> Although, an (almost) equivalent userspace code would be:
> 
> mount_fooat(int fd, const char *path)
> {
> 	char tmpbuf[64];
> 	int tmpfd = openat(fd, path);
> 
> 	sprintf(tmpbuf, "/proc/self/fd/%i", tmpfd);
> 	return mount_foo(tmpbuf, ...);
> }
>
> Or is there something (other than not requiring proc) that the *at
> variant gives?

The ability to have a daemon handle mounting onto a directory that only
exists in another process's private namespace.

Say I'm running in my private namespace that contains paths that are not
shared by the trusted 'init' namespace. If I were to step on an
autofs-like trap, I'd like for the kernel to be able to notify the
automounter that is running in the trusted namespace set up by 'init',
and have it mount the directory onto my namespace. This should happen
even if the path is not shared.

With mountat() the kernel can still pass the necessary information to
the automounter by giving it a directory file descriptor 'fd' that
points to the directory on top of which it wants the mount to occur.
Then automounter then executes

     mountat(AT_FDCWD, dev_name, fd, '.', type, flags, data);

and hey presto, the magic occurs.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/