The nss_ldap and pam_ldap packages that are masked as ~x86, namely nss_ldap-209 and pam_ldap-161 cause a segmentation fault upon use. Dropping down to the stable packages nss_ldap-207-r1 and pam_ldap-156 solves this problem. I think these packages should be in package.mask...unless I am misunderstanding the purpose of package.mask. Anyway if there IS a resolution to this seg fault issue then that would be great, otherwise it would be nice if they were masked out. Reproducible: Always Steps to Reproduce: 1. turn on ACCEPT_KEYWORDS="~x86" however you want (make.conf or ACCEPT_KEYWORDS="~x86" emerge package 2.emerge openldap pam_ldap nss_ldap (verify u have versions 209 and 161 for nss_ldap and pam_ldap respectivly) 3. Configure your slapd (not sure if this is necessary) 4. Configure /etc/pam.d/system_auth to use pam_ldap.so 5. Configure /etc/nsswitch.conf to use ldap by adding ldap after files for each of the first three sections (passwd, shadow, group). 6. Start nscd 7. Try getting information about a user using id, or su someone and it should seg fault. Actual Results: Segmentation Fault Expected Results: Either ided/sued the user sucessfully or returned some sort of error such as invalid password or user doesn't exist, etc. slapd was running as was nscd, if you strace id or su it occurs right after reading a certain configuration file, some after reading ldap.conf others after /etc/security/limits.conf.
I verified the existance of this bug. I built with -mcpu=athlon. It segfaults consistently on my system after reading /etc/ldap.conf, but only if that file contains either a "uri" or "host" directive. The file can contain anything, so long as it does not have either of those. I don't show any debug output from slapd at all.
By the way, sorry about this but I built with -march=athlon-xp -O3 -pipe -fomit-frame-pointer, I have not seen any other problem with these CFLAGS.
did you try recompile both after ldap recompile ? also try #revdep-rebuild from gentoolkit
also try out new version in bug #23362
The problem is in nss_ldap-209. Pam I confirm this is a problem as well. To attach: 1. Patch that adds lots of debugging to nss_ldap-209 2. patch to ebuild that adds support for IUSE="debug" and adds the extra debugging patch. Then I built with: FEATURES="nostrip" USE="debug" CFLAGS="-g" emerge nss_ldap 3. Normal debug output. 4. GDB backtrace. I crashed my development box at work, so I'll attach these in the morning. I strongly recommend hard masking nss_ldap-209 because of this bug. I haven't tested Chet's comment yet.
As to Chet's comment. If you don't have either uri or host in your /etc/ldap.conf The nss_ldap doesn't kick in at all. I've grabbed another machine to produce a GDB backtrace for now. Coming shortly.
Built with: FEATURES="noclean keepwork keeptemp nostrip" CFLAGS="-ggdb" USE="debug" emerge nss_ldap GDB Backtrace: #0 0x40150522 in _nss_ldap_map_get (config=0x401599e0, type=MAP_ATTRIBUTE, rfc2307attribute=0x401587ef "uid", value=0xbfffd590) at ldap-nss.c:3244 #1 0x401503b3 in _nss_ldap_atmap_get (config=0x401599e0, rfc2307attribute=0x401587ef "uid", attribute=0xbfffd590) at ldap-nss.c:3174 #2 0x4015008f in _nss_ldap_map_at (attribute=0x401587ef "uid") at ldap-nss.c:3056 #3 0x401547cc in init_pwd_attributes (pwd_attrs=0x40159aa8) at ldap-schema.c:284 #4 0x401546eb in _nss_ldap_init_attributes (attrtab=0x40159aa8) at ldap-schema.c:260 #5 0x4014de34 in do_open () at ldap-nss.c:1035 #6 0x4014f542 in _nss_ldap_search (args=0x0, filterprot=0x40162580 "", sel=LM_PASSWD, sizelimit=0, msgid=0xbfffde8c, csd=0x804f134) at ldap-nss.c:2412 #7 0x4014f7f8 in _nss_ldap_getent (ctx=0x401590f8, result=0x401492ac, buffer=0x804f140 "", buflen=1024, errnop=0x40148320, filterprot=0x40162580 "", sel=LM_PASSWD, parser=0x40150768 <_nss_ldap_parse_pw>) at ldap-nss.c:2606 #8 0x40150cd1 in _nss_ldap_getpwent_r (result=0x401492ac, buffer=0x804f140 "", buflen=1024, errnop=0x40148320) at ldap-pwd.c:247 #9 0x40107bd4 in __nss_getent_r () from /lib/libc.so.6 #10 0x400c9016 in getpwent_r@@GLIBC_2.1.2 () from /lib/libc.so.6 #11 0x401077e4 in __nss_getent () from /lib/libc.so.6 #12 0x400c8b60 in getpwent () from /lib/libc.so.6 #13 0x0804a025 in setgrent () #14 0x0804a987 in setgrent () #15 0x400317a7 in __libc_start_main () from /lib/libc.so.6 That line is: #0 0x40150522 in _nss_ldap_map_get (config=0x401599e0, type=MAP_ATTRIBUTE, rfc2307attribute=0x401587ef "uid", value=0xbfffd590) at ldap-nss.c:3244 3244 if ((((DB *) map)->get) ((DB *) map, map is NULL at that point. Hence the crash :-(.
That was on DB-4.1 originally. DB-4.0 produces an identical segfault. Turning off --enable-schema-mapping causes nss_ldap to go infinitely deep.
207-r1, without DB4 works fine using either DB-4.* _or_ 209 causes problems it seems. I'm hardmasking 209 for now. I'll ask pauldv about the DB4 issue.
nss_ldap-209.1 has been added to portage supporting the berkdb, debug, and ssl USE variables. The ssl one was tricky as it isn't a documented use flag. db3 is required for berkdb support and consequently --enable-rfc2307bis If you are still having segfault problems, please test with USE="-ssl"
nss_ldap-210 is now in portage. Please test.
Due to the recent power outage in my area (Cleveland, Ohio), i managed to update only last night. I'm happy to say that I was able to login this morning with the new nss-ldap, but I will continue testing it before I truly say that its working. (I havn't had time to restart nscd, reboot the system, etc.) Also USE="pic crypto X gtk2 gnome kde ldap samba pam tcpd ssl qt -nas -lirc pam -arts -alsa -cups -nls -i18n" and CFLAGS="-march=athlon-xp -O3 -pipe". I have pam_ldap-156 and nss_ldap-210 along with openldap-2.0.27-r4. SSL is not enabled in my ldap conf since I don't expect connections over lo to be sniffed, I will test SSL sometime in the near future (next few weeks).
hm, this doesn't work for me. tested with pam_ldap-156 and nss_ldap 210, keeps segfaulting. right now i have most recent pam_ldap (161 i think), but it still doesn't work. i tried to run 'getent -s ldap passwd' through gdb, it crashes at vfprintf in libc. oh btw, db 4-*
Patrick: please make sure nscd is running as nss_ldap 100% requires it installed AND running to work properly.
thanks for pointing that out, i thought it was optional (it works now :))
closing this now.
