Re: TODO entry for getgrouplist

[Jim Meyering]

"James Youngman" <address@hidden> wrote:
> The current coreutils TODO file says:-
>
> Implement Ulrich Drepper's suggestion to use getgrouplist rather than
>   getugroups.  This affects both `id' and `setuidgid', but makes a big
>   difference on systems with many users and/or groups, and makes id usable
>   once again on systems where access restrictions make getugroups fail.
>   But first we'll need a run-test (either in an autoconf macro or at
>   run time) to avoid the segfault bug in libc-2.3.2's getgrouplist.
>   In that case, we'd revert to using a new (to-be-written) getgrouplist
>   module that does most of what `id' already does.  Or just avoid the
>   buggy use of getgrouplist by never passing it a buffer of length zero.
>   See http://bugzilla.redhat.com/200327
>
> This seems to me to imply that there are safe usages of getgrouplist()
> on arbitrary systems.  Specifically, that the problem is the zero
> length of the buffer.

Right.

> However the manpage for that function says :
>
>        The glibc 2.3.2 implementation of this function  is  broken:  it  over‐
>        writes memory when the actual number of groups is larger than *ngroups.
>
> So, is it safe to use getgrouplist() with an iniital value of 1 for
> *ngrouplist?

Yes, that is my understanding, too.

If you're suggesting that it'd be best to avoid the problematic usage (and
thus not to rely on a configure-time test), then you're on the right track.
Then the code will work even when a binary built on a system with newer
glibc is run on a system with the broken function.