[Pkg-shadow-devel] [test] newuidmap/newgidmap
serge.hallyn at ubuntu.com
Tue Jun 3 16:58:18 UTC 2014
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
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.
> If one would want to enforce subids for root, one may want to investigate a
> /proc/.../subuid interface. That could probably leave the whole restriction
I'm not sure what you mean here.
> process in the kernel, remove the need for newuidmap and have the administrator
> allocate subuids for himself before using them.
> In any case, the thing here is about assumptions. newuidmap is not a front-end
> but a dedicated tool.
A dedicated privileged tool for use by other tools, to localize the very careful
handling needed to delegate this stuff safely.
> To avoid confusion, the manual should be more factual and
> recommend checking the mapping with the kernel for a definitive answer.
I think you're saying you want an update to newuidmap(1), but I don't understand
what. Can you give some proposed text?
> P. Grégoire
More information about the Pkg-shadow-devel