Set supplementary groups by default, allow users to modify supplementary groups

Question

Set supplementary groups by default, allow users to modify supplementary groups

Closed this issue 9 years ago · 6 comments

In addition to the real and effective group ID of a process, every process has a list of supplementary groups IDs. From the credentials(7) man page on Linux:

Supplementary group IDs. This is a set of additional group IDs that are used for permission checks when accessing files and other shared resources. On Linux kernels before 2.6.4, a process can be a member of up to 32 supplementary groups; since kernel 2.6.4, a process can be a member of up to 65536 supplementary groups. The call sysconf(_SC_NGROUPS_MAX) can be used to determine the number of supplementary groups of which a process may be a member. A process can obtain its set of supplementary group IDs using getgroups(2), and can modify the set using setgroups(2).

See the related Chef bug here: https://tickets.opscode.com/browse/CHEF-3510

Programs such as sudo and su typically set the list of supplementary groups to the groups of which the EUID is a member.

In C, the relevant system calls to modify the group list are initgroups and setgroups

In Ruby, the group list can be modified with the Process.groups= method.

Answer 1 · 2014-11-03T21:00:21.000Z

@sersut My opinion would be to change this issue from Enhancement to Bug. This problem prevents valid use cases from functioning correctly.

Answer 2 · 2014-11-03T22:52:24.000Z

That's just a semantic argument, it won't make any difference for getting it fixed.

Answer 3 · 2014-11-05T03:44:28.000Z

@lamont-granquist Indeed, sorry.

I started looking at this and it seems that Process.initgroups does exactly this, i.e. setting Process.groups with all groups user has access to.

Doing this implicitly is probably the right fix but may have unintended consequences. I will prepare a PR so we can discuss this.

Matt

Answer 4 · 2014-11-05T04:25:42.000Z

Yeah looks simple enough on the surface of it... I don't think there's any downside to it either. It gives the process more rights than it initially had so there should only be use case where it does not fail and now succeeds. And its not getting any rights that it shouldn't have access to, its just getting all the rights that it has a claim to. Seems like if anyone is broken by this that it'd be an xkcd 1172.

Answer 5 · 2015-04-01T18:57:21.000Z

Affected customer in 3656

Answer 6 · 2015-05-15T02:08:23.000Z

with_login fixes are merged