linux-kernel - Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor

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, 28 Feb 2008 16:08:20 +0900
From:	Ian Kent <raven@...maw.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	autofs mailing list <autofs@...ux.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...nvz.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor

On Wed, 2008-02-27 at 22:37 -0800, Andrew Morton wrote:
> On Thu, 28 Feb 2008 15:22:27 +0900 Ian Kent <raven@...maw.net> wrote:
> 
> > 
> > > > +++ linux-2.6.25-rc2-mm1/fs/autofs4/waitq.c	2008-02-20 13:10:23.000000000 +0900
> > > > @@ -363,6 +363,38 @@ int autofs4_wait(struct autofs_sb_info *
> > > >  
> > > >  	status = wq->status;
> > > >  
> > > > +	/*
> > > > +	 * For direct and offset mounts we need to track the requestor
> > > > +	 * uid and gid in the dentry info struct. This is so it can be
> > > > +	 * supplied, on request, by the misc device ioctl interface.
> > > > +	 * This is needed during daemon resatart when reconnecting
> > > > +	 * to existing, active, autofs mounts. The uid and gid (and
> > > > +	 * related string values) may be used for macro substitution
> > > > +	 * in autofs mount maps.
> > > > +	 */
> > > > +	if (!status) {
> > > > +		struct dentry *de = NULL;
> > > > +
> > > > +		/* direct mount or browsable map */
> > > > +		ino = autofs4_dentry_ino(dentry);
> > > > +		if (!ino) {
> > > > +			/* If not lookup actual dentry used */
> > > > +			de = d_lookup(dentry->d_parent, &dentry->d_name);
> > > > +			ino = autofs4_dentry_ino(de);
> > > > +		}
> > > > +
> > > > +		/* Set mount requestor */
> > > > +		if (ino) {
> > > > +			if (ino) {
> > > > +				ino->uid = wq->uid;
> > > > +				ino->gid = wq->gid;
> > > > +			}
> > > > +		}
> > > > +
> > > > +		if (de)
> > > > +			dput(de);
> > > > +	}
> > > > +
> > > 
> > > But uids and gids are no longer system-wide-unique.  Two different users
> > > can have the same identifiers in different namespaces.  What happens then?
> > 
> > That's a tricky question.
> > 
> > Presumably, the process requesting the mount has the user space daemon
> > running in the namespace within which the uid and gid are to be looked
> > up, by the daemon.
> > 
> > Am I missing something?
> > 
> 
> err, you assume more knowledge at this end about what you're trying to do
> than actually exists :)
> 
> You seem to imply that if a machine is running 100 user namespaces then it
> needs to run 100 mount daemons.  Doesn't seem good.

More likely my lack of understanding of how namespaces are meant to
work.

> 
> What problem are you actually trying to solve here?

The basic problem arises only when we want to restart the user space
daemon and there are active autofs managed mounts in place at exit (ie.
autofs mounts that have busy user mounts). They are left mounted and
processes using them continue to function. But then, when we startup
autofs we need to reconnect to these autofs mounts, some of which can
covered the by mounted file systems, and hence the need for another way
to open an ioctl descriptor to them.

It may have been overkill to re-implement all the current ioctls (and
add a couple of other much needed ones) but I though it sensible for
completeness, and we get to identify any possible problems the current
ioctls might have had due to the use of the BKL (by the VFS when calling
the ioctls).

So, why do we need the uid and gid? When someone walks over an autofs
dentry that is meant to cause a mount we send a request packet to the
daemon via a pipe which includes the process uid and gid, and as part of
the lookup we set macros for several mount map substitution variables,
derived from the uid and gid of the process requesting the mount and
they can be used within autofs maps.

This is all fine as long as we don't need to re-connect to these mounts
when starting up, since we don't get kernel requests for the mounts, we
need to obtain that information from the active mount itself.

Ian

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