"James Youngman" <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
