Bug#466647: libnss-ldap: incorrect return code for getgrent()
Coin, After browsing the web i found this bug was supposed to be fixed in version 260, which seems to be right according to my tests. -- Marc Dequènes (Duck) pgpPExBIQVIbX.pgp Description: PGP signature
Bug#466647: libnss-ldap: incorrect return code for getgrent()
On Thu, 2008-02-21 at 17:04 +, Richard A Nelson wrote: I ran a test against libnss-ldapd, and it does not have this issue - one more advantage it has over libnss-ldap :) I ran into this a while back (while developing nss-ldapd). The Glibc documentation seems to suggest that the NSS module you should set errno when returning the last entry (NSS_STATUS_NOTFOUND): http://www.gnu.org/software/libc/manual/html_node/NSS-Modules-Interface.html#NSS-Modules-Interface This does not seem to be true. The problem was not there before so it probably depends on the version of Glibc and coreutils used. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#466647: libnss-ldap: incorrect return code for getgrent()
On Wed, 20 Feb 2008, Jon DeVree wrote: The symptom that shows in id seems to depend on how many groups someone is in. So its not terribly easy to test for on an arbitrary system. So I wrote a different program to test for the bug. If it prints getpwent() errno = 2 after dumping the user/uid mapping then it hit the ENOENT error. Ah, thanks - that reliably shows there error here, even on systems where `id` appears to work fine. Did this perchance start with the move to the newer libldap ? I can reproduce it with: libnss-ldap_251-7.5etch1 - libldap2_2.1.30.dfsg-13.5 libnss-ldap_258-1+b1 - libldap-2.4-2_2.4.7-5 libnss-ldap_259-1- libldap-2.4-2_2.4.7-5 A good data point, thanks... so it isn't a new problem, 'tis odd that it hasn't been more widely seen (google/padl bug page/changelog don't seem to find anything relevant) ! I'll wager your earlier guess about this being related to an earlier problem is dead-on. If you want me to run a test slapd server of a different version I can, but that will take longer to setup. No need, I doubt it is slapd, but thought there might be something related to the newer libldap (and needed -DDEPRECATED for compiling). I've tested some other libnss modules and nss-ldap is the only one that gives an ENOENT when it hits the end of the list. I ran a test against libnss-ldapd, and it does not have this issue - one more advantage it has over libnss-ldap :) I'm not really setup to test any other libnss-* setups. I'll go make another pot of coffee, grab some copenhagen and pre-emptively take some advil before jumping back into the code it is not bad in spots, there just aren't enough of those spots :) -- Jon You're talking about a group of people who are paid large sums of money for their ability to communicate with inanimate objects made of melted sand. -NANOG :) Our signatures are on a similar train of thought -- Rick Nelson Electro my computer was once one of the building blocks of a great pyramid -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466647: libnss-ldap: incorrect return code for getgrent()
On Wed, 20 Feb 2008, Jon DeVree wrote: The expected behavior of libnss-ldap is that at the end of the group list getgrent() returns NULL and leaves errno unchanged. How libnss-ldap actually behaves is that getgrent() returns NULL and errno is set to ENOENT. This results in problems for a few programs like id becaues getgrent() is not behaving as documented in the manpages. This is odd, very odd... out of 5 systems at hand (all current Sid, 2 x86_64, the rest x86_32), only one exhibits this erroneous behaivour. Then, on the one system, only system users (not fully in LDAP) return that error - general user accounts (ie cowboy) work just fine. Did this perchance start with the move to the newer libldap ? -- Rick Nelson It's not usually cost effective time wise to go do it. But if something's really pissing you off, you just go find the code and fix it and that's really cool. -- John Carmack, on the advantages of open source -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466647: libnss-ldap: incorrect return code for getgrent()
On Wed, Feb 20, 2008 at 11:54:03AM -0800, Richard A Nelson wrote:
Then, on the one system, only system users (not fully in LDAP) return
that error - general user accounts (ie cowboy) work just fine.
The symptom that shows in id seems to depend on how many groups someone
is in. So its not terribly easy to test for on an arbitrary system. So I
wrote a different program to test for the bug. If it prints getpwent()
errno = 2 after dumping the user/uid mapping then it hit the ENOENT error.
Did this perchance start with the move to the newer libldap ?
I can reproduce it with:
libnss-ldap_251-7.5etch1 - libldap2_2.1.30.dfsg-13.5
libnss-ldap_258-1+b1 - libldap-2.4-2_2.4.7-5
libnss-ldap_259-1- libldap-2.4-2_2.4.7-5
If you want me to run a test slapd server of a different version I can,
but that will take longer to setup. I
I've tested some other libnss modules and nss-ldap is the only one that
gives an ENOENT when it hits the end of the list.
--
Jon
You're talking about a group of people who are paid large sums of money for
their ability to communicate with inanimate objects made of melted sand.
-NANOG
#include errno.h
#include pwd.h
#include stdio.h
#include stdlib.h
#include string.h
#include sys/types.h
#include unistd.h
int main(int argc, char **argv) {
errno = 0;
setpwent();
if( errno != 0 ) {
fprintf(stderr, setpwent() errno = %d\n, errno);
}
for(;;) {
errno = 0;
struct passwd *ent = getpwent();
if( ent == NULL || errno != 0 ) {
fprintf(stderr, getpwent() errno = %d\n, errno);
break;
}
printf(%s : %d\n, ent-pw_name, ent-pw_uid);
}
errno = 0;
endpwent();
if( errno != 0 ) {
fprintf(stderr, endpwent() errno = %d\n, errno);
}
return 0;
}
Bug#466647: libnss-ldap: incorrect return code for getgrent()
Package: libnss-ldap Version: 259-1 Severity: normal The expected behavior of libnss-ldap is that at the end of the group list getgrent() returns NULL and leaves errno unchanged. How libnss-ldap actually behaves is that getgrent() returns NULL and errno is set to ENOENT. This results in problems for a few programs like id becaues getgrent() is not behaving as documented in the manpages. # id -a root uid=0(root) gid=0(root)id: failed to get groups for user `root': No such file or directory This is also a problem with getpwent() and presumably the rest of the calls of a similar nature that can fall back to libnss-ldap. I also have a hunch that this is the underlying cause of bug #427497 but I can't duplicate that specific behavior to check. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libnss-ldap depends on: ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy ii libc6 2.7-8 GNU C Library: Shared libraries ii libcomerr21.40.6-1 common error description library ii libkrb53 1.6.dfsg.3~beta1-3 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.7-5OpenLDAP libraries ii libsasl2-22.1.22.dfsg1-18Cyrus SASL - authentication abstra Versions of packages libnss-ldap recommends: ii libpam-ldap 184-3 Pluggable Authentication Module al pn nscd none (no description available) -- debconf information: * libnss-ldap/dblogin: false libnss-ldap/override: true * shared/ldapns/base-dn: dc=setec * shared/ldapns/ldap-server: ldap * libnss-ldap/confperm: false * libnss-ldap/rootbinddn: cn=manager,dc=example,dc=net * shared/ldapns/ldap_version: 3 libnss-ldap/binddn: cn=proxyuser,dc=example,dc=net * libnss-ldap/nsswitch: * libnss-ldap/dbrootlogin: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
