LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Ian Kent <raven@themaw.net>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	Jeff Moyer <jmoyer@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	autofs mailing list <autofs@linux.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Pavel Emelyanov <xemul@openvz.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor
Date: Fri, 29 Feb 2008 10:09:21 -0600	[thread overview]
Message-ID: <20080229160921.GA24296@sergelap.ibm.com> (raw)
In-Reply-To: <1204255932.3969.86.camel@raven.themaw.net>

Quoting Ian Kent (raven@themaw.net):
> 
> On Thu, 2008-02-28 at 13:51 -0600, Serge E. Hallyn wrote:
> > Quoting Jeff Moyer (jmoyer@redhat.com):
> > > Ian Kent <raven@themaw.net> writes:
> > > 
> > > > On Wed, 2008-02-27 at 23:23 -0800, Andrew Morton wrote:
> > > >> On Thu, 28 Feb 2008 16:08:20 +0900 Ian Kent <raven@themaw.net> wrote:
> > > >> > 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.
> > > >> 
> > > >> yeah, could be a problem.  Hopefully the namespace people can advise. 
> > > >> Perhaps we need a concept of an exportable-to-userspace namespace-id+uid,
> > > >> namespace-id+gid, namespace-id+pid, etc for this sort of thing.  It has
> > > >> come up before.  Recently, but I forget what the context was.
> > > >
> > > > I'm all ears to any feedback from others on this, please.
> > > 
> > > I think there is some confusion surrounding what the UID and GID are
> > > used for in this context.  I'll try to explain it as best I can.
> > > 
> > > When the automount daemon parses a map entry, it will do some amount of
> > > variable substitution.  So, let's say you're running on an i386 box, and
> > > you want to mount a library directory from a server.  You might have a
> > > map entry that looks like this:
> > > 
> > > lib	server:/export/$ARCH/lib
> > > 
> > > In this case, the automount daemon will replace $ARCH with i386, and
> > > will try the following mount command:
> > > 
> > > mount -t nfs server:/export/i386/lib /automountdir/lib
> > > 
> > > There are cases where it would be helpful to use the requesting
> > > process's UID in such a variable substitution.  Consider the case of a
> > > CIFS share, where the automount daemon runs as user root, but we want to
> > > mount the share using the credentials of the requesting user.  In this
> > > case, the UID and GID can be helpful in formatting the mount options for
> > > mounting the share.
> > > 
> > > So, the UID and GID are used only for map substitutions.  Now, having
> > > said all of that, I'll have to look more closely at why we even need to
> > > keep track of it, given that it only needs to be used when performing
> > > the lookup, and at that time we have information on the requesting UID
> > > and GID.
> > 
> > Thanks Jeff.  If that's the case then user namespaces don't affect this
> > at all.
> 
> Yep, that's precisely the way this is used, by autofs anyway.
> 
> I guess the problem we face is that since this is a public interface
> other applications could use this in a different way and we can't
> control that. I think I need more information so I can document the
> defined usage in my revised patch set.
> 
> In version 5 I set $UID, $GID, $USER, $GROUP and $HOME in addition to
> the standard autofs macros, $ARCH, $CPU, $HOST, $OSNAME, $OSREL and
> $OSVERS, and then expand the map entry.
> 
> The question that Jeff is asking himself is, why do we need this
> information when we re-connect at startup, since the mounts are already
> present.
> 
> The answer isn't easy to explain and will be lengthy, sorry, but let me
> try anyway.
> 
> There are two types on maps, direct (in the module source you will see a
> third type called an offset, which is just a direct mount in disguise)
> and indirect.
> 
> For example, here is master map with direct and indirect map entries:
> 
> /-	/etc/auto.direct
> /test	/etc/auto.indirect
> 
> /etc/auto.direct:
> 
> /automount/dparse/g6  budgie:/autofs/export1
> /automount/dparse/g1  shark:/autofs/export1
> and so on.
> 
> /etc/auto.indirect:
> 
> g1    shark:/autofs/export1
> g6    budgie:/autofs/export1
> and so on.
> 
> For the above indirect map an autofs file system is mounted on /test and
> mounts are triggered by the inode lookup operation. So we see a mount of
> shark:/autofs/export1 on /test/g1, for example.
> 
> The way that direct mounts are handled is by makeing an autofs mount on
> each full path, such as /automount/dparse/g1, and using it as a mount
> trigger. So when we walk on the path we mount shark:/autofs/export1 on
> top of this mount point, for example. Since these are always a
> directories we can use the follow_link inode operation to trigger the
> mount.
> 
> But, each entry in direct and indirect maps can have offsets (often
> called multi-mount map entries).
> 
> For example, 
> 
> a direct mount map entry could also be:
> 
> /automount/dparse/g1 \
>     /       shark:/autofs/export5/testing/test \
>     /s1     shark:/autofs/export/testing/test/s1 \
>     /s2     shark:/autofs/export5/testing/test/s2 \
>     /s1/ss1 shark:/autofs/export2 \
>     /s2/ss2 shark:/autofs/export2
> 
> and a similar indirect mount:
> 
> g1    \  
>    /        shark:/autofs/export5/testing/test \
>    /s1      shark:/autofs/export/testing/test/s1 \
>    /s2      shark:/autofs/export5/testing/test/s2 \
>    /s1/ss1  shark:/autofs/export1 \
>    /s2/ss2  shark:/autofs/export2
> 
> One of the issues with version 4 of autofs was that, when mounting an
> entry with a large number of offsets, possibly with nesting, we needed
> to mount and umount all of them as a single unit. Not really a problem,
> except for people with a large number of offsets in map entries. This
> mechanism is used for the well known "hosts" map and we have seen cases
> (in 2.4) where the available number of mounts are exhausted or where the
> number of privileged ports available is exhausted.
> 
> In version 5 we mount only as we go down the tree of offsets and
> similarly for expiring them which resolves the above problem. There is
> somewhat more detail to the implementation but it isn't needed for the
> sake of the explanation. The one important detail is that these offsets
> are implemented using the same mechanism as the direct mounts above and
> so can also be covered by another mount.
> 
> To be able to do this I need to maintain context. In the daemon I use a
> list to represent these offsets and use it to manage the mounting and
> expiration of the mount tree, something which can only be discovered
> from the original map entry. So, to rebuild this context at startup for
> existing mounts I need to do the lookup to get the map entry as part of
> the process of re-connecting to the mounts. Hence the need to get the
> uid and gid of the original requester.

The way the user namespaces work right now is similar to say the IPC
namespace - a task belongs to one user, that user belongs to precisely
one user namespace.

Even in my additional userns patches, I was changing uid to store the
(uid, userns) so a struct user still belonged to just one user
namespace.

In contrast, with pid namespaces a task is associated with a 'struct
pid' which links it to multiple process ids, one in each pid namespace
to which it belongs.

Perhaps we should be treating user namespaces like pid namespaces?

For autofs this would mean that when autofs wants a uid for some task,
it would be given the uid in the user namespace which autofs 'knows'.

It would also help me fix the siginfo problems I haven't solved yet -
rather than having to worry about user namespace lifetimes with siginfos
(which last a little while but have no clearly defined lifespan) we
could send the uid in an init user namespace or the uid in the target
uid namespace, or just a lightweight user struct proxy akin to 'struct
pid'.

And it also obviates the need for any sort of delegation.

So if I'm user 500 in what I think is the initial user namespace, I can
create a container with a new user namespace, the init task of which is
both uid 0 in the child userns, and uid 500 in the higher level,
automatically giving the container access to any files I own.

Eric, when you get a chance (I know you're overloaded atm) I'd love to
hear your thoughts on this...

> Few, that was hard work, just for those last couple of sentences.
> 
> Please, lets not go into the issue that the maps can change during a
> restart, that's an issue for another time and isn't a kernel issue
> anyway. 
> 
> > 
> > (Still trying to follow the rest of the thread bc i definately feel like
> > I'm missing something.  I swear I understood autofs 10+ years ago :)
> 
> Me too, but now I've change it so much even I'm confused most of the
> time, ;)
> 
> Hopefully the above explanation is useful in some small way.
> 
> Ian
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2008-02-29 16:10 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26  3:21 [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Ian Kent
2008-02-26  3:22 ` [PATCH 1/4] autofs4 - check for invalid dentry in getpath Ian Kent
2008-02-26  3:23 ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor Ian Kent
2008-02-26  5:14   ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor - correction Ian Kent
2008-02-28  4:45   ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor Andrew Morton
2008-02-28  6:22     ` Ian Kent
2008-02-28  6:37       ` Andrew Morton
2008-02-28  7:08         ` Ian Kent
2008-02-28  7:23           ` Andrew Morton
2008-02-28  8:00             ` Ian Kent
2008-02-28 17:13               ` Jeff Moyer
2008-02-28 19:51                 ` Serge E. Hallyn
2008-02-29  3:32                   ` Ian Kent
2008-02-29 16:09                     ` Serge E. Hallyn [this message]
2008-02-29 16:20                       ` Pavel Emelyanov
2008-02-29 17:42                         ` Serge E. Hallyn
2008-03-02  0:49                       ` Eric W. Biederman
2008-03-02  1:13                       ` Eric W. Biederman
2008-03-03 15:28                         ` Serge E. Hallyn
2008-03-04 22:16                           ` Eric W. Biederman
2008-02-28  7:51           ` Pavel Emelyanov
2008-02-28  7:59             ` Andrew Morton
2008-02-28  8:06               ` Ian Kent
2008-02-28 12:31                 ` [autofs] " Fabio Olive Leite
2008-02-28 20:33             ` Eric W. Biederman
2008-02-26  3:23 ` [PATCH 4/4] autofs4 - add miscelaneous device for ioctls Ian Kent
2008-02-28  5:17   ` Andrew Morton
2008-02-28  6:18     ` Ian Kent
2008-03-13  7:00       ` [RFC] " Ian Kent
2008-03-14  2:45         ` Ian Kent
2008-03-14 12:45         ` Thomas Graf
2008-03-14 14:10           ` Ian Kent
2008-02-29 16:24     ` Ian Kent
2008-04-11  7:02       ` Ian Kent
2008-04-12  4:03         ` Andrew Morton
2008-04-14  4:45           ` Ian Kent
2008-02-26  4:29 ` [PATCH 2/4] autofs4 - add mount option to display mount device Ian Kent
2008-02-28  5:17   ` Andrew Morton
2008-02-28  4:40 ` [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Andrew Morton
2008-02-28  6:07   ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080229160921.GA24296@sergelap.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=autofs@linux.kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=xemul@openvz.org \
    --subject='Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).