On 22 Sep 2015 14:40, Eric W. Biederman wrote:
> Mike Frysinger 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.
i don't want to drop groups ... i want the exact opposite actually :).
ideally, `id` would have the same output before/after. instead, i get
65534 for all the supplemental groups. these commands work before i
create a new userns and i want them to keep working afterwards:
chgrp 100 foo
chgrp 250 foo
instead, only the first works (since that's my effective gid) and the
second fails (since i'm in that via a supplemental group).
> 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.
i know i can get it ahead of time if i have the caps apriori, but that's
not what i want to require. if i had those, then i would generally be
able to simply create the namespaces directly and not bother with userns
in the first place :).
> > 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.
if setgroups is set to deny, then it's not possible for me to drop any
groups, and therefore allowing me to map supplemental groups wouldn't be
a problem right ?
-mike
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
