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

[Philippe Grégoire]

On 2014-06-03 20:02:12 (+0000), Serge Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm at xmission.com):
> > 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.
> 

Eric, you seem to place best practice first. Which is fine, but contradicts the
idea that root can do 'rm -rf /*'. And, why would root use containers in the
first place?

By leaving newuidmap unchanged and toolsets relying on it, they must bail out if
the administrator doesn't have subids defined. It follows best practice, but
root expects to have no restrictions. Also, the kernel doesn't care about policy
so if one tool follows best practice, another might not. Which goes against the
principle you are trying to enforce.

If you really care about best practice, put /etc/sub*id in the kernel and have
roots be disciplined by allocating unique ranges. If not, newuidmap could be
modified for SETUID users (so assumptions are respected), or else document the
exception in the manual (i.e.: no subuids, no mapping).

P.G.