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.
