Theodoros V. Kalamatianos discovered that getgrent mistakenly
sets errno=ENOENT on EOF when /etc/nsswitch.conf specifies e.g.,
group: nisplus
This causes some new getgrent failure-detection code to report a
false positive for the bogus ENOENT.
[getgrent returns NULL both to indicate EOF and to indicate an error.
Setting errno=0 beforehand and checking it afterwards is the only
way to distinguish failure and EOF. ]
This came up because a program used in coreutils testing framework
would fail for root-only tests (not a big deal):
# ./setuidgid +0 true > /dev/null
./setuidgid: failed to get groups for user `root': No such file or directory
But you can demonstrate the same effect with "id" from the
just release coreutils-6.10:
$ ./id root
uid=0(root) gid=0./id: failed to get groups for user `root': No such file or
directory
As such, and considering the POSIX recommendation to avoid getgrent, I'll
soon finally switch to using get getgrouplist, per this TODO file entry:
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
Now that there are two clients, we definitely need a getgrouplist
module for gnulib. If someone writes it in the next few days,
that'd be great. Otherwise, I'll get to it.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
