Re: [patch] 5.95: getgrouplist

[Jim Meyering]

Tim Waugh <address@hidden> wrote:
> Here is a patch that makes use of getgrouplist() if it is available,
> for better efficiency.

Hi Tim,

Thanks for posting that.
Making this improvement is mentioned in the TODO file,
but there's a caveat.  Using getgrouplist on libc-2.3.2
is documented to fail.  From the man page:

  BUGS
       The glibc 2.3.2 implementation of this function is broken:
       it overwrites memory when the actual number of groups is
       larger than *ngroups.

I confirmed that back in Oct 2004.
I tried some simple code to use it, and it would *always* segfault.
Looked like it was tramping on a libc-internal buffer.

Here's the entry from coreutils/TODO:

  Implement Ulrich Drepper's suggestion to use getgrouplist rather
    than getugroups.  This affects only `id', 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.

It'd be great if someone would write a gnulib-style getgrouplist
replacement function that provides a poor-man's implementation (using
something like coreutils' existing code) for systems that lack a useful
function by that name.

Jim