On Thu, 28 Feb 2008 15:22:27 +0900 Ian Kent <raven@xxxxxxxxxx> 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.
What problem are you actually trying to solve here?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
