public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Serge Hallyn <serge.hallyn@canonical.com>,
	Oleg Nesterov <oleg@redhat.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [rfc] fcntl: Add F_GETOWNER_UIDS option
Date: Thu, 29 Mar 2012 02:30:53 +0000	[thread overview]
Message-ID: <20120329023053.GA10187@mail.hallyn.com> (raw)
In-Reply-To: <20120328213736.GM2204@moon>

Quoting Cyrill Gorcunov (gorcunov@openvz.org):
> On Wed, Mar 28, 2012 at 04:30:44PM -0500, Serge Hallyn wrote:
> > Quoting Oleg Nesterov (oleg@redhat.com):
> > > On 03/28, Serge E. Hallyn wrote:
> > > >
> > > > If you want to
> > > > just add the struct cred to the f_owner and do proper uid conversion,
> > > > I'll support that too.  (Just grab a ref to the cred in
> > > > fs/fcntl.c:f_modown(), and drop the ref in fs/file_table.c:__fput() ).
> > > 
> > > In this case f_owner.*uid should go away, I guess.
> > 
> > Yup.
> > 
> > Which I guess is all the more reason *not* to do this unless we end up
> > not going with Eric's userns mapping patchset (which is unlikely).
> > 
> > > And sigio_perm()
> > > should be unified with kill_ok_by_cred() somehow (modulo
> > > security_file_send_sigiotask).
> > > 
> > > Right?
> > 
> > Maybe, but other differences include current being the signal sender in
> > one and recipient in the other, and CAP_KILL being relevent in only
> > one.
> 
> Hi Serge, thanks a lot for comments! Replying to prev email --
> I've skipped cred part intentionally, I guess we need to wait
> until Eric's patches hit LKML (if I understand all right) then
> I'll expand the patch. I'll think a bit more tomorrow, ok?

Sure.

Thinking about it, the cred being stored right now is the cred in the
container.  That's what you want for checkpoint, right?  So if someone
with the privs to do it checkpoints a task in a child userns, and restarts
that without doing so in a child user ns, he should be allowed to do so.

So what I'm saying is that it's not in-defensible to just not change
anything in your original patch until we can discuss Eric's set.

If we were to *not* go with Eric's set, then when using your proposed
patch for debugging purposes, would we want to show a list of uids,
starting with the uid in the reader's user namespace, up to the
container being investigated?  So for instance if init_user_ns spawned
userns1, and that spawned userns2, and root in userns1 is seeking this
info for a f_owner in userns2, then he should see two userids, the one
mapped into usern1, and the one in userns2.

In Eric's set, we may want to show only the kuid (since the mapped
userid can be found other ways), or for convenience we may want to show
both the kuid and the mapped uid.

-serge

  reply	other threads:[~2012-03-29  2:30 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
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 [this message]
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=20120329023053.GA10187@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=serge.hallyn@canonical.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