[Bug 220779] getgroups result is affected by setegid

Bruce Evans brde at optusnet.com.au
Mon Jul 17 07:41:51 UTC 2017


On Sun, 16 Jul 2017 a bug that doesn't want replies at freebsd.org wrote:

> ...
>           Summary: getgroups result is affected by setegid
> ...
>          Reporter: muh.muhten at gmail.com
>
> On FreeBSD, the groups applicable to a process are stored in an array with the
> egid in [0] and and zero or more (not necessarily distinct) additional gids in
> sorted order.
>
> The setgid, setegid, and setregid functions change the egid of a process, but
> the process's supplementary group ids are to remain unchanged. Since getgroups,
> which claims to conform to IEEE Std 1003.1-2008 (“POSIX.1”), is defined to fill
> its second argument with calling process's supplementary group ids, so its

No, its second arg is filled with the egid and then the supplementary group
ids.

> output must not include the egid, which is changed by setgid &c.. The current
> implementation fills the second argument with the entire groups array, which
> does include the egid in [0].

Slot [0] is the non-supplementary part of the list.

> - "The setgid() function shall not affect the supplementary group list in any
> way. Any supplementary group IDs of the calling process shall remain
> unchanged."
> - "The setegid() function shall not affect the supplementary group list in any
> way."
> - (ditto for setregid)

Satisified since setting the gid only changes slot [0] in the list.

> - "The getgroups() function shall fill in the array grouplist with the current
> supplementary group IDs of the calling process. It is implementation-defined
> whether getgroups() also returns the effective group ID in the grouplist
> array."

This is what allows FreeBSD to return the gid in slot [0].

> - "A process has up to {NGROUPS_MAX} supplementary group IDs in addition to the
> effective group ID."

So in implementations that return the egid in the array, the array can have
length 1 + {NGROUPS_MAX} elements.  POSIX says this too.

FreeBSD used to have an off-by-1 bug in this area.  It used to have a limit
of {NGROUPS_MAX} elements in the array.  So it didn't actually support
{NGROUPS_MAX} supplementary gids, but 1 less than that.  When I looked at
that many years ago, I suspected that it had the bug in this PR, but I
can't see this bug now.

There are still bugs in this area:
- FreeBSD doesn't document its implementation-defined behaviour that
   getgroups() returns the egid in the array.  It's getgroups(2) man
   page doesn't use the POSIX term "supplementary group" at all, but uses
   the generic term "group list".
- POSIX doesn't require getgroups() to return the egid in any particular
   place in the array (or disallow returning it more than once if there is
   space to spare).  So it is not a bug for FreeBSD to not document the
   particular place that it uses, but applications have a difficult time
   determining which ids in the list are supplementary.
- POSIX is not completely clear about disallowing multiple filling of the
   list with supplementary ids when there is space to spare, or about wasting
   space so that there is not enough.  The 2001 version even seems to allow
   expanding the return value beyond 1 + {NGROUPS_MAX} in the case where
   the egid is not returned, to provide enough space after wasting some.

Bruce


More information about the freebsd-standards mailing list