On Wed, 2016-05-04 at 10:02 -0500, Eric W. Biederman wrote: > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > > > On Thu, 2016-04-28 at 16:00 -0700, W. Trevor King wrote: > > > On Thu, Apr 28, 2016 at 03:02:08PM -0700, James Bottomley wrote: > > > > /etc/usernamespaces > > > > > > > > and the format be ::: > > > > > > > > … > > > > > > > > If this sounds OK to people, I can code up a utility that does > > > > this, which should probably belong in util-linux. > > > > > > This sounds a lot like shadow's newuidmap and newgidmap [1,2,3]. > > > > > > Cheers, > > > Trevor > > > > > > [1]: https://github.com/shadow-maint/shadow/commit/673c2a6f9aa6c6 > > > 9588f4c1be08589b8d3475a520 > > > [2]: http://man7.org/linux/man-pages/man1/newuidmap.1.html > > > [3]: http://man7.org/linux/man-pages/man5/subuid.5.html > > > > I think that mostly works. No-one's packaging it yet, which is why > > I didn't notice. It also looks like the build dependencies have > > vastly expanded, so I can't get it to build in the build service > > yet. > > Both Fedora and Ubuntu should be packaging it. Further Docker should > already be using these files. > > > It looks like the only addition it needs is the setgroups flag for > > newgidmap, which the security people will need, so I can patch > > that. Plus it's trying to install newgidmap/newuidmap as setuid > > root rather than cap_setuid/cap_setgid, but that's fixable in the > > spec file. > > I read the rest of this thread and I don't understand the setgroups > flag that you desire. It sounds like someone with an incomplete > grasp on the situtation being cautious. > > As far as I can tell the use cases for containers not supporting > setgroups is very limited. Basically just using user namespaces to > drop privileges, and mapping the existing uids and gids to 0. > > I don't think it actually makes sense to have a knob. From a > practical standpoint entering any subordinate ids into the subgid > file for a user is a permission to use groups in such a way that can > not use them as a negative acl (because we allow them to be dropped). > > Certainly it has been that way for quite a while now. I don't quite get this. If setgroups is set to deny and I have a set of group mappings, I still can't get rid of the negative acl group. I can map it to a different gid inside my container, or I can not map it at all, but in either case I still can't get access to anything with the negative acl group marker because the group permission checks occurs with the kguid_t set which includes my mapped or unmapped group. The only way I can lose it is to call sys_setgroups(). It's a bit ugly because I have to enter the container with --preserve -credentials and I can't su to myself if I enter as root (-S 0), I have to re-enter as myself instead, but it works. > Except for the negative acl aspect there are no issues with dropping > groups, as setgroups will limit you to the groups allowed in your > user namespace. Well, notwithstanding the merits of negative acls, which I don't want to debate because I don't think they're that useful, the use case might be that a user possessing a negative acl still wants to use an architecture emulation container for building. Installing such a container requires being able to set a set of groups and uids (required by the installer), but it doesn't require the sys_setgroups() system call, so they could reasonably be given the ability to set one up with the nosetgroups flag and a range of gids allocated in subgid to ensure they still can't get access to resources denied by the negative acl group. James _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
