[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO entry for getgrouplist

From: Jim Meyering
Subject: Re: TODO entry for getgrouplist
Date: Sat, 16 Feb 2008 18:40:54 +0100

"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.


> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]