linux-kernel - Re: [rfc] fcntl: Add F_GETOWNER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Mar 2012 02:30:53 +0000
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	Oleg Nesterov <oleg@...hat.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [rfc] fcntl: Add F_GETOWNER_UIDS option

Quoting Cyrill Gorcunov (gorcunov@...nvz.org):
> On Wed, Mar 28, 2012 at 04:30:44PM -0500, Serge Hallyn wrote:
> > Quoting Oleg Nesterov (oleg@...hat.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
--
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/