The trouble with dropping groups

Posted Nov 20, 2014 21:26 UTC (Thu) by skissane (subscriber, #38675)
In reply to: The trouble with dropping groups by luto
Parent article: The trouble with dropping groups

How about modifying struct group_info to add a flags word for each supplementary group? One bit of the flags word would be used to indicate if the supplementary group is droppable by unprivileged callers, the others would be reserved for future use. Add new setgroups2() system call which allows privileged processes to set the flags words when the groups are set, and allow getgroups2() to allow unprivileged callers to retrieve both the groups and the associated flags.

The trouble with dropping groups

Posted Nov 20, 2014 21:37 UTC (Thu) by luto (guest, #39314) [Link] (1 responses)

The problem with that is that existing userspace won't understand it at all. Without something clever, one side effect is likely to be that it will completely disable unprivileged user namespaces on most systems.

The trouble with dropping groups

Posted Nov 21, 2014 0:48 UTC (Fri) by skissane (subscriber, #38675) [Link]

I would expect that setgroups() / getgroups() would still work, setgroups() would just zero the flags words. (Alternatively, if we call setgroups() with an already present group, it could leave the flags word for that group unchanged.) So yes, for this to be usable, privileged userspace code which calls setgroups() would need to be modified to call setgroups2(). Without that change, existing userspace code should still work, it just wouldn't be able to access the droppable groups feature. In order to use the droppable groups feature, you'd need to update user space code which calls setgroups() to call setgroups2() instead with the desired flags word (reading it from NSS groups database I presume). [Of course, setgroups2() should fail if an attempt is made to set a reserved bit to a non-zero value.]