[Pkg-shadow-devel] [test] newuidmap/newgidmap

[Serge Hallyn]

Quoting Eric W. Biederman (ebiederm at xmission.com):
> Serge Hallyn <serge.hallyn at ubuntu.com> writes:
> 
> > Quoting Philippe Grégoire (gregoirep at hotmail.com):
> >> On 2014-06-03 15:38:05 (+0000), Serge Hallyn wrote:
> >> > Quoting Philippe Grégoire (gregoirep at hotmail.com):
> >> > 
> >> > I personally still feel as you do, that root should be a special case who can
> >> > do as he likes;  OTOH it's not an unreasonable argument that (a) root can do
> >> > as he likes manually anyway, and (b) requiring this gives some default
> >> > protective isolation of subuids for root.
> >> 
> >> Actually, I believe that, because root can do arbitrary mappings using /proc,
> >> there is no _need_ for an exception.
> >
> > So you're happy with the status quo?  (There is currently no exception, only
> > ranges authorized by /etc/subuid are allowed)
> >
> >> The main goal here is to prevent collisions and privilege escalations if users
> >> were allowed to do arbitrary mappings. /etc/subuid allows just that by enabling
> >> users to do mappings (with the help of a SETUID program) to ranges specified by
> >> the administrator (or programmatically, in the case of adduser). While it is
> >> true that root can have subids, it cannot be enforced, utltimately, by
> >> newuidmap.
> >
> > It can't be enforced.  However, noone except while playing around with it is
> > going to manually set up uid mappings.  They'll use a toolset, let's, oh, say,
> > lxc-usernsexec.  Not having this exception for root means that all such
> > toolsets will need to have a separate code path for the root user writing
> > to /proc/$$/uid_map, while the main code path uses newuidmap.  That's a
> > recipe for untested paths and errors.
> 
> But it is not.

Agreed since we can allocate ranges for root as for anyone else it's
fine.

Which leaves only,

> Root should be documenting which uids root uses in containers in
> /etc/subuid just like everyone else.  That will allow sysadmins
> to figure out what is going on.
> 
> So if you document what is going on, the only case that will fail for
> root are for uids that you did not intend to use.  I don't see that as a
> bad thing, and certainly I don't see it impeding code reuse.
> 
> Why should root owned containers be special and not have to document
> which uids they use?

Because root is special, and people expect that they can just do things
as root, especially if the kernel doesn't prevent it.

I'm not saying this pursuades me.  I'm saying I consider this only as
valid of an argument as the below.

> Why should root owned containers not have to worry
> about using uids that someone is using for something else?

They very much do have to, which I've always said is the flipside
argument.  That it is useful for protecting root from unpriv users.

-serge