bug-coreutils
[Top][All Lists]
Advanced

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

getgrouplist module is now higher priority


From: Jim Meyering
Subject: getgrouplist module is now higher priority
Date: Wed, 23 Jan 2008 22:53:10 +0100

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.




reply via email to

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