Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor

[Serge E. Hallyn]

Quoting Pavel Emelyanov (xemul@xxxxxxxxxx):
> > The way the user namespaces work right now is similar to say the IPC
> > namespace - a task belongs to one user, that user belongs to precisely
> > one user namespace.
> > 
> > Even in my additional userns patches, I was changing uid to store the
> > (uid, userns) so a struct user still belonged to just one user
> > namespace.
> > 
> > In contrast, with pid namespaces a task is associated with a 'struct
> > pid' which links it to multiple process ids, one in each pid namespace
> > to which it belongs.
> > 
> > Perhaps we should be treating user namespaces like pid namespaces?
> 
> I'm afraid, that I'm just starting a new thread of discussion in a
> wrong place, but I can't refrain from asking "what for?"

For the reasons I listed there :)

> > So if I'm user 500 in what I think is the initial user namespace, I can
> > create a container with a new user namespace, the init task of which is
> > both uid 0 in the child userns, and uid 500 in the higher level,
> > automatically giving the container access to any files I own.
> 
> So do you mean that I can become a root, by calling clone()?

You can become root in the new container.  Your capabilities are
meaningful only to targets (users, files) which exist in the user
namespace in which you are root.  It becomes more precise than the
CAP_NS_OVERRIDE approach in my last patchset.

> Thanks,
> Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/