Message-ID: <m1fxva3q6h.fsf@ebiederm.dsl.xmission.com>
Date:	Sat, 01 Mar 2008 17:49:58 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Ian Kent <raven@...maw.net>, Jeff Moyer <jmoyer@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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>
Subject: Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor

"Serge E. Hallyn" <serue@...ibm.com> writes:

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

I definitely think we should have some support like that.

We already have code in nfsv4 and p9fs if I remember correctly to make
between the user namespace of the server (which is string based) and
the uids of the local machine.

We also have a similar issue with security keys.

I don't know if the strict hierarchical nature we have makes a lot of
sense.  One of the things that we should account for is that
frequently user namespaces are kept in sync between multiple machines
by system administrators.  So in the real world user namespaces are a
system administrator boundary.

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

Yes.  The user namespace of the process that opened the pipe I believe
is the right choice there.

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

Yes.  For the pids we have been looking at sending the pid in the
target namespace and sending the uid in the target namespace should be
no more difficult.

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

Right.

Long term we want to look at making this an unprivileged operation.
Allowing a user to run less privileged processes.

My impression has always been that going from comparing (userns, uid)
to a more sophisticated mapping approach was a compatible extension.
However if it looks like we need user namespace mapping support up
front to get the semantics clean I have no problem with that.

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

I think you are on the right track.  In a lot of ways the user
namespace is the trickiest, as this is where we change the security
rules.  If it is only at the level of who is who.

Since we already have user namespace mapping infrastructure in the
kernel and ways to call back to user space to ask what the mapping
should be, I feel performing mapping in the user namespace
and generalizing the existing capability is a good idea.

We still want to tell users if you can get away with it synchronize
your user namespaces across file systems, and kernels, and machines.

If they can't having good general tools in the kernel that you only
need to learn once and not once per instance sounds good.

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

Powered by blists - more mailing lists