public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>,
	Oleg Nesterov <oleg@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	"Serge E. Hallyn" <serge.hallyn@canonical.com>
Subject: Re: [rfc] fcntl: Add F_GETOWNER_UIDS option
Date: Tue, 27 Mar 2012 19:22:48 -0700	[thread overview]
Message-ID: <m162dpo45j.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20120327224640.GA5328@mail.hallyn.com> (Serge E. Hallyn's message of "Tue, 27 Mar 2012 22:46:40 +0000")

"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Cyrill Gorcunov (gorcunov@openvz.org):
>> On Tue, Mar 27, 2012 at 10:29:23PM +0000, Serge E. Hallyn wrote:
>> > Quoting Cyrill Gorcunov (gorcunov@openvz.org):
>> > > On Tue, Mar 27, 2012 at 05:25:34PM +0200, Oleg Nesterov wrote:
>> > > > user_ns_map_uid() should translate uid_t from one namespace to another,
>> > > > in this case the namespace is the same.
>> > > > 
>> > > > user_ns_map_uid(cred->user_ns, cred) must be the identical mapping,
>> > > > no matter how we change the implementation.
>> > > > 
>> > > > What I think you need is
>> > > > user_ns_map_uid(current_user_ns(), filp->f_owner.cred), the only
>> > > > problem is that f_owner.cred doesn't exist.
>> > > > 
>> > > 
>> > > Hmm, I was confused by likely() in user_ns_map_uid. But indeed, I think
>> > > you're so right. Is there some reason why we can't carry f_owner.cred
>> > > pointer?
>> > 
>> > We would need that for this, yes.  However, Eric is working on a new
>> > patchset which changes the cross-userns uid mappings.  I think it's
>> > worth simply leaving a comment that this will need to be addressed,
>> > and leave in the unconverted uid.
>> 
>> Hi Serge, thanks for info. But if it will be unconverted uid, can't
>> be there some security problem with that which I missed?

I would suggest the easy route and create a KCONFIG dependency
on !CONFIG_USER_NS until the code for that is a little farther along.

Hopefully later this week or begginning of next week I should be posting
my patches and seeing how well the rest of the world takes them.

> Noone is really using the user namespaces right now, but rather than
> adding the cred (and refcounting concerns), my suggestion for now
> would be to hardcode a check in modown() that current_user_ns() ==
> &init_user_ns.
>
> I *did* have a patch in the past which added the cred to fown, but
> no idea where it is right now...

So I guess there are two questions.
- Does it make sense besides translation to add a cred here in general?

- How will it work with the user_namespace?

  I am just about ready to post a patchset that at the edges of
  userspace maps all uid and gids into uid and gids in the initial user
  namespace.

  There is a lot of noise but in net the code is terribly simple, easy
  to maintain and measurably faster (when compiled out) than what we are
  doing now, and most importantly it has a reasonable chance of catching
  all of the permission checks.

  And I have already converted fcntl.  So once my patchset goes in it
  should take all of 5 seconds to get the compile error and fix the code
  to be user_namespace friendly.

Eric


  reply	other threads:[~2012-03-28  2:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26 15:09 [rfc] fcntl: Add F_GETOWNER_UIDS option Cyrill Gorcunov
2012-03-26 16:43 ` Oleg Nesterov
2012-03-26 18:33   ` Cyrill Gorcunov
2012-03-27 15:25     ` Oleg Nesterov
2012-03-27 16:58       ` Cyrill Gorcunov
2012-03-27 22:29         ` Serge E. Hallyn
2012-03-27 22:34           ` Cyrill Gorcunov
2012-03-27 22:46             ` Serge E. Hallyn
2012-03-28  2:22               ` Eric W. Biederman [this message]
2012-03-28  6:48                 ` Cyrill Gorcunov
     [not found]                   ` <m1k425mae1.fsf@fess.ebiederm.org>
2012-03-28  7:55                     ` Cyrill Gorcunov
2012-03-28  8:16                       ` Cyrill Gorcunov
2012-03-28 19:43                         ` Serge E. Hallyn
2012-03-28 19:46                           ` Oleg Nesterov
2012-03-28 21:30                             ` Serge Hallyn
2012-03-28 21:32                               ` Oleg Nesterov
2012-03-28 21:37                               ` Cyrill Gorcunov
2012-03-29  2:30                                 ` Serge E. Hallyn
2012-03-30 12:31                                   ` Cyrill Gorcunov
2012-03-30 14:12                                     ` Serge Hallyn
2012-03-30 14:40                                       ` Cyrill Gorcunov
2012-03-30 16:15                                         ` Serge E. Hallyn
2012-03-30 19:46                                           ` Kees Cook
2012-03-30 19:56                                             ` Cyrill Gorcunov

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=m162dpo45j.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=gorcunov@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=serge.hallyn@canonical.com \
    --cc=serge@hallyn.com \
    --cc=xemul@parallels.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox