Re: [PATCH] Add MS_BIND_FLAGS mount flag

[Miklos Szeredi]

> 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.

I understand perfectly that this is what you want to do.  And I'm
saying that the following code snippet should do exactly the same,
without having to add a new syscall:

	char tmpbuf[64];
	sprintf(tmpbuf, "/proc/self/fd/%i", fd);
	mount(dev_name, tmpbuf, type, flags, data);

[ You could actually try to read people's responses, instead of
immediately assuming they don't understand :-/ ]

So again, what is the advantage of a mountat() syscall over just using
the proc trick?

Miklos
--
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/