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

Serge E. Hallyn
2006-07-14T14:03:38Z

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