Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

On Fri, Feb 17, 2017 at 12:53 PM, Aleksa Sarai wrote:

quoted

quoted

quoted

quoted

One thing overlooked by commit 9cc46516ddf4 ("userns: Add a knob to
disable setgroups on a per user namespace basis") is that because
setgroups(2) no longer works in user namespaces it doesn't make any
sense to be returning weird group IDs that the process cannot do
anything with.

quoted

bool DropPrivileges()
{
        /* ... */
      // Verify that the user isn't still in any supplementary groups

But the user *is* still in a supplementary group.  Your proposed
change would break the intent of this code.

I was about to say that "being in an unmapped supplementary group does
not count as privileges", but decided to test it first and realised that
this is not true? How is this not a blatant security vulnerability?

whether they're mapped is irrelevant.  if you make modifications to
the FS, the permission check counts against the meaning of the ids in
the parent namespaces.  otherwise your argument is like saying "i
mapped my UID to 0 in this new usernamespace, so how is that not a
blatant security vuln".

if you started out with access to the group, then keeping that access
doesn't grant you any new privs you didn't already have.

% touch somefile
% chmod 660 somefile
% sudo chown root:wheel somefile
% unshare -r
% cat somefile
% # no EACCES...

you didn't show `id` before the `unshare`.  if you're already in the
wheel group, what you've shown here is not a bug.
-mike