linux-kernel - Re: [PATCH] Add MS_BIND

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Feb 2008 14:17:55 -0500
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	menage@...gle.com, viro@...iv.linux.org.uk,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] Add MS_BIND_FLAGS mount flag

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/