All of lore.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>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Oleg Nesterov <oleg@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	keescook@chromium.org
Subject: Re: [rfc] fcntl: Add F_GETOWNER_UIDS option
Date: Fri, 30 Mar 2012 16:15:00 +0000	[thread overview]
Message-ID: <20120330161500.GA32247@mail.hallyn.com> (raw)
In-Reply-To: <20120330144035.GC2024@moon>

Quoting Cyrill Gorcunov (gorcunov@openvz.org):
> On Fri, Mar 30, 2012 at 09:12:19AM -0500, Serge Hallyn wrote:
> ...
> > > 
> > > Yes, I wanna take a look on Eric's set first just to get right
> > > "picture" of everything. And I wanted to find a minimal solution
> > > with current kernel code base which could be extended in future.
> > > 
> > > That said I guess the current init-ns-only approach should do the
> > > trick for a while. And (thanks for pointing) I need to add a test
> > > if a caller which tries to obtain uids has enought credentials
> > > for that (probably CAP_FOWNER), right?
> > 
> > Sorry, I'm not sure which caller you mean.  Neither f_setown nor
> > f_getown require privilege right now.  Oh, you mean at restart?
> 
> I meant the dumper. Yes, at moment f_get/setown requires no privileges
> but I'm not sure if uid/euid is same or less sensible information
> than pid, that's why I though CAP_FOWNER might be worth to add, no?

Hmm, I would say no, but that might be a good question for kees.

IMO it's not sensitive information and so no sense requiring privilege
(and encouraging handing out of extra privilage to get at the info)

Cc:ing kees.

> > f_setown to someone else's uid/pid means you may cause a signal to
> > be sent to them.  So CAP_KILL might be good?  You do through that
> > signal get *some* info about the file writes, though not contents.
> > So yeah, maybe (CAP_KILL|CAP_FOWNER).
> ...
> > > I suspect operating with kuid's will be a way more easier.
> > 
> > Yeah, I keep going back and forth on which makes more sense.  But
> > kuid's probably make more sense, even though they aren't what
> > userspace in container will see.  When you restore, the mapping
> > will give userspace what it expects;  and if you're going to
> > restart in a container with a different mapping, then you'll
> > have to convert the filesystem as well since its inodes will
> > store kuids, so may as well also convert the kuids in the
> > checkpoint image then.
> 
> Agreed (if only I'm not missimg somethig ;)
> 
> 	Cyrill

  reply	other threads:[~2012-03-30 16:15 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
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 [this message]
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=20120330161500.GA32247@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@openvz.org \
    --cc=keescook@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.