LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Ian Kent <raven@themaw.net>, 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>
Subject: Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor
Date: Sat, 01 Mar 2008 17:49:58 -0700	[thread overview]
Message-ID: <m1fxva3q6h.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20080229160921.GA24296@sergelap.ibm.com> (Serge E. Hallyn's message of "Fri, 29 Feb 2008 10:09:21 -0600")

"Serge E. Hallyn" <serue@us.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

  parent reply	other threads:[~2008-03-02  0:53 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
2008-02-29 16:20                       ` Pavel Emelyanov
2008-02-29 17:42                         ` Serge E. Hallyn
2008-03-02  0:49                       ` Eric W. Biederman [this message]
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=m1fxva3q6h.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=autofs@linux.kernel.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=serue@us.ibm.com \
    --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).