Tim Waugh <[EMAIL PROTECTED]> 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
