handling of supplemental groups with userns
Eric W. Biederman
ebiederm at xmission.com
Tue Sep 22 19:40:07 UTC 2015
Mike Frysinger <vapier at gentoo.org> writes:
> is it possible to map in supplemental groups in a userns when the user
> lacks setgid/etc... capabilities in the parent ns ? it doesn't seem
> like it's currently possible, but is there a reason to not enable it ?
In your unprivileged use scenario, you won't be able to drop
your supplementary groups so why do you need them mapped?
> basically i have a build tool that i want to isolate a bit, but it
> requires access to some of my supplemental groups. if i map just
> my effective uid/gid, the build will fail when it tries to use the
> chown/chgrp commands (gets back EINVAL).
Yes. That really isn't valid as you are dropping groups. Peculiarly
enough dropping groups can be a security issue as in some permission
checks not being a member of a group can give you enhanced access to
files and directories.
So to do something like what you want, you need a setuid helper (something
like newuidmap or newgidmap) to verify that what you are doing is ok
by local policy.
> my scenario boils down to:
> - normal unprivileged user (uid=8282)
> - member of multiple groups (gid=100, getgroups={100,16,250,...})
> - create a new userns (to get access to other ns like mount/pid)
> but still have access to existing groups where i'm root
> - use various features that require caps (new pidns/mntns/etc...)
> - create another userns and map back non-root users/groups
> i.e. i switch from 8282 to 0, do what i need, then switch back to 8282.
[snip]
> in the mean time, a "quick" fix might be to change new_idmap_permitted
> to walk all the extents, and if all the ranges are set to 1, check the
> supplemental groups in addition to the current egid ?
That allows dropping groups that you could not drop normally and so we
can't allow it, by default.
Eric
More information about the Containers
mailing list