GNU Core Utilities - Bugs: bug #22505, id command fails to retrieve group...
You are not allowed to post comments on this tracker with your current authentication level.
bug #22505: id command fails to retrieve group info when nss_ldap is used
Submitter: | None | ||
Submitted: | Thu 06 Mar 2008 06:39:43 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | Confirmed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Mon 10 Mar 2008 10:07:27 AM UTC, comment #2: |
Ralf Haferkamp <rha> |
Sat 08 Mar 2008 09:39:12 AM UTC, comment #1: Thank you for the report and the patch.
However this is fixed (or at least made less likely) in the latest snapshot (http://meyering.net/cu/coreutils-ss.tar.lzma) by virtue of the code now using getgrouplist when that function is available.
Since getgrent is supposed to leave errno unchanged upon EOF, I believe this exposes a bug in glibc (also note that ENOENT is not listed as a possible errno value in the POSIX spec for getgrent). It would seem that few getgrent-using applications care enough about robustness to check this particular condition.
So, regarding your patch, it'd be nice if you would investigate the possibility this is a glibc bug and get it fixed upstream. Considering the failure is no longer triggered with the latest coreutils snapshot, and the behavior it accommodates is not even standard-conforming, I'm inclined not to use the patch. |
Jim Meyering <meyering>![]() |
Thu 06 Mar 2008 06:39:43 PM UTC, original submission:
coreutils-6.10
By just installing nss_ldap and adding it to passwd, group and shadow in /etc/nsswitch.conf, the below happens:
[root@pandora ~]# id miura
but:
Notice that it is not even required to have an ldap server around, nor to configure /etc/ldap.conf.
Downgrading to coreutils-6.9 makes the problem go away.
I tracked it to a change in getugroups() and came up with the attached patch.
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Regarding nss_ldap, I guess that this was a bug in nss_ldap it was setting errno explicitly to ENOENT. That problem should be fixed with the latest nss_ldap release (260).
Probably the NSS module handling nisplus has the same problem.