Re: [PATCH -mm 5/7] add user namespace

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> Dave Hansen <haveblue@us.ibm.com> writes:
> >> 
> >> > On Thu, 2006-07-13 at 12:14 -0600, Eric W. Biederman wrote:
> >> >> Maybe.  I really think the sane semantics are in a different uid namespace.
> >> >> So you can't assumes uids are the same.  Otherwise you can't handle open
> >> >> file descriptors or files passed through unix domain sockets.
> >> >
> >> > Eric, could you explain this a little bit more?  I'm not sure I
> >> > understand the details of why this is a problem?
> >> 
> >> Very simply.
> >> 
> >> In the presence of a user namespace.  
> >> All comparisons of a user equality need to be of the tuple (user namespace,
> > user id).
> >> Any comparison that does not do that is an optimization.
> >> 
> >> Because you can have access to files created in another user namespace it
> >> is very unlikely that optimization will apply very frequently.  The easy
> > scenario
> >> to get access to a file descriptor from another context is to consider unix
> >> domain sockets.
> >
> > What does that have to do with uids?  If you receive an fd, uids don't
> > matter in any case.  The only permission checks which happen are LSM
> > hooks, which should be uid-agnostic.
> 
> You are guest uid 0.  You get a directory file descriptor from another namespace.
> You call fchdir.
> 
> If you permission checks are not (user namespace, uid) what can't you do?

File descripters can only be passed over a unix socket, right?

So this seems to fall into the same "userspace should set things up
sanely" argument you've brought up before.

Don't get me wrong though - the idea of using in-kernel keys as
cross-namespace uid's is definately interesting.

-serge