Re: getgroups improvements

[Jim Meyering]

Eric Blake wrote:
> According to Eric Blake on 11/12/2009 11:41 AM:
>> getgroups replaces a library function, so it should not exit().  On the other
>> hand, the mgetgroups interface from coreutils is much nicer to use (one call,
>> instead of 2); that would be a reasonable place to add an xalloc-die
>> dependency, but this patch does not do that.
>
> On at least FreeBSD, even if you belong to exactly one group, getgroups()
> returns both the effective gid and the entire list of supplemental gids;
> if the effective gid is part of the list of supplemental gids, that means
> the same group is listed twice.  For example:
>
> $ /usr/bin/id
> uid=84137(blake) gid=84137(blake) groups=84137(blake)
> $ ./gltests/test-getgroups a
> 84137
> 84137

The same thing happens on GNU/Linux, so this would
mean a change in behavior for id invoked with no arguments.
However, considering that in that case, the output format is
deliberately not fully specified, few applications should
be parsing it.

> Should we make mgetgroups smarter to sort and/or eliminate duplicate
> entries?  Maybe make it conditional via the addition of a bool flag?
> Without sorting, it's O(n^2) unless we use a hash; with sorting, it is O(n
> log n); or we can just do pairwise duplicate elimination with an O(n)

I'd go with the pairwise approach (thinking they'll often/always
be adjacent) or even O(n^2).  With the former, you could add a
test, calling mgetgroups for every user on the system, that will
trigger if it misses a duplicate.  With the latter, you could
choose a threshold and fail a test if any user belongs to more
than say, 1,000 groups.

> pass.  Then there's the issue of whether there will ever be enough groups
> to notice scaling effects if we do make the decision to reduce or avoid
> duplicates.