I use pam-0.75-r8 ebuild and userdb.so to authenticate some users (ftp). The relevant line in my pam config is (/etc/pam.d/vsftpd) auth sufficient /lib/security/pam_userdb.so db=/etc/userdb.db The .db file was generated with the following command: dbload -T -t hash -f input_file /etc/userdb.db where the input_file had usernames and passwords on alternating lines (plain text). Now this far everything works. Just wanted to tell to ease up the reproduction. Now when I try to log in and tail vsftpd log: [vsftpd] PAM unable to dlopen(/lib/security/pam_userdb.so) [vsftpd] PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: __db_ndbm_open] [vsftpd] PAM adding faulty module: /lib/security/pam_userdb.so and the login fails. No idea how to fix this.
*** Bug 9393 has been marked as a duplicate of this bug. ***
*** Bug 9462 has been marked as a duplicate of this bug. ***
(from the gentoo-dev mailing list) glib-1.2.x was the problem all right. I also re-emerged readline, python, libtools, and a bunch of other ancillary stuff in my quest for a solution, but it seems glib was the main culprit. Problem is, I didn't know where to find it to do a re-emerge. emerge -s glib didn't list it. I now know it's under sys-devel, but it took some poking and proding to discover this. Once I found it, I simply re-emerged (didn't unmerge anything first).
--> "(from the gentoo-dev mailing list) glib-1.2.x was the problem all right" Does it mean re-emerging glib+pam would work ? Is there a quick hack to make PAM work, it is really really blocking for services authentification (pop, imap...).
*** Bug 9477 has been marked as a duplicate of this bug. ***
*** Bug 9483 has been marked as a duplicate of this bug. ***
Is this *really* a glib bug ? I trapped the same problem on alpha with gdm ! during compile of gdm, gdm-binary IS (!) linked against pam (-lpam) but doing an ldd on the resulting binary will NOT show libpam.so in the linklist !! Thats unless I repeat the link-step and exchange "-lpam" with "/lib/libpam.so.0" After that gdm authorizes just fine without any complaints about unresolved symbols. As to the solution , so remerging glib can solve this ? So what has been changed in the glib ebuild so that it finally avoids the pam problem . If something has been changed, why hasnt it gotten a new revision number ?
Could it be the latest libtool? I just upgraded it yesterday and after recompiling uw-imap my mail is not working any more (as I already mentioned in the forum, I don't have GDM/Gnome and my system is GCC-2.95.3 based) Problem is that I can't downgrade libtool, because there is no ebuilds for previous versions of it.
BTW, imap binary is not linked against libpam! root # ldd `which login` libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x40025000) libpam.so.0 => /lib/libpam.so.0 (0x40028000) libdl.so.2 => /lib/libdl.so.2 (0x40031000) libc.so.6 => /lib/libc.so.6 (0x40035000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) root # ldd `which su` libcrypt.so.1 => /lib/libcrypt.so.1 (0x40025000) libcrack.so.2 => /usr/lib/libcrack.so.2 (0x40052000) libpam.so.0 => /lib/libpam.so.0 (0x4005e000) libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x40067000) libc.so.6 => /lib/libc.so.6 (0x4006a000) libdl.so.2 => /lib/libdl.so.2 (0x4019a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) root # ldd `which kdm` libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40017000) libXau.so.6 => /usr/X11R6/lib/libXau.so.6 (0x400df000) libpam.so.0 => /lib/libpam.so.0 (0x400f0000) libdl.so.2 => /lib/libdl.so.2 (0x400f9000) libresolv.so.2 => /lib/libresolv.so.2 (0x400fd000) libutil.so.1 => /lib/libutil.so.1 (0x4010f000) libc.so.6 => /lib/libc.so.6 (0x40113000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) root # ldd `which imapd` libdl.so.2 => /lib/libdl.so.2 (0x40025000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40029000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40056000) libc.so.6 => /lib/libc.so.6 (0x40111000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Same for me... # ldd `which imapd` libdl.so.2 => /lib/libdl.so.2 (0x001e0000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x001e3000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x00214000) libc.so.6 => /lib/libc.so.6 (0x002df000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x001c6000) Everything that has been said about this bug and imap/pop is happening to my servers too...
there's a big thread on Gentoo forums about this bug: http://forums.gentoo.org/viewtopic.php?t=19176&highlight=gdm+pam ... but no one found a solution yet, at least not for the imap / pop authentication problem.
"env LD_PRELOAD=/lib/libpam.so.0.75 ${command}" seems to fix the problem, at least with gdm. So, how to set this as a systemwide environment variable?
Workaround: Make a symbolic link that points to /lib/libpam[.so[.0[.75]]] in any directory in /etc/ld.so.conf, like this: ln -s /lib/libpam /usr/local/lib/libpam Then, either env-update or reboot
LD_PRELOAD works for imap/pop, but modifying /etc/ld.so.conf doesn't.
Ignore my previous comment. Do this instead: echo "/lib/libpam.so" >> /etc/ld.so.preload This will be the equivalent of doing an export LD_PRELOAD="/lib/libpam.so"
To solve my imap/pop problem I had to first unmerge all instances of pam & uw-imap and then reemerge latest versions of them (i.e. pam-0.75-r9) Now everything seems to work properly: root # ldd `which imapd` libpam.so.0 => /lib/libpam.so.0 (0x40025000) libdl.so.2 => /lib/libdl.so.2 (0x4002e000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40032000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005f000) libc.so.6 => /lib/libc.so.6 (0x4011a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
so guys, looks like its a static lib, gcc include dir order thing? as azarah's released -r9, i trust you're all using/trying it? should be close this, and open a new one against -r9 if neccesary? i dunno how useful this information is, sitting here. the root cause seems to have been discovered, so...
Well, I emerged r9, but I still have the same problem with imapd/pop3 authentification if I don't issue: echo "/lib/libpam.so" >> /etc/ld.so.preload So, for me, that makes no difference with r8.
Well, I have just emerged pam-0.75-r9 and remerged all packages with a direct dependency to it, and ldd `which gdm` indicates it is linked to libpam.so.0. Two days ago, I manually linked gdm-binary to /lib/libpam.so.0 and removed /lib/libpam.so from /etc/ld.so.preload, and it was solved. I do not have imapd so I cannot offer any advice other than modifying the Makefiles and recompiling manually. [Change -lpam to /lib/libpam.so.0]
I emerged the new pam-0.7.5-r9 package and removed the old one. After that I emerged the vsftpd again. Still pam_userdb.so module says: Oct 25 19:47:15 [vsftpd] PAM unable to dlopen(/lib/security/pam_userdb.so) Oct 25 19:47:15 [vsftpd] PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: __db_ndbm_open] Oct 25 19:47:15 [vsftpd] PAM adding faulty module: /lib/security/pam_userdb.so There is no /usr/lib/libpam* nor was there any while I recompiled vsftpd. Something still wrong here.
*** This bug has been marked as a duplicate of 4411 ***