When trying to implement virtual users for vsftpd I get the following errors in syslog Nov 3 16:19:21 uberserver vsftpd: PAM unable to dlopen(/lib/security/pam_userdb.so) Nov 3 16:19:21 uberserver vsftpd: PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: __db_ndbm_close_4000] Nov 3 16:19:21 uberserver vsftpd: PAM adding faulty module: /lib/security/pam_userdb.so I've tried re-emerging PAM with the berkdb USE flag, but to no avail. Reproducible: Always Steps to Reproduce: 1. Follow the instructions at ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-1.2.0/EXAMPLE/VIRTUAL_USERS/README 2. Try to login via ftp 3. Actual Results: Authentication failed Expected Results: Authenticated me for ftp Portage 2.0.49-r15 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r8, 2.6.0-test9) ================================================================= System uname: 2.6.0-test9 i686 VIA Nehemiah Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -pipe -msse -mfpmath=sse -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4 -falign-labels=1 -falign-loops=16 -falign-jumps=16 -fomit-frame-pointer -fstack-protector" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -march=i686 -pipe -msse -mfpmath=sse -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4 -falign-labels=1 -falign-loops=16 -falign-jumps=16 -fomit-frame-pointer -fstack-protector" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/ ftp://ftp.fhh.opensource-mirror.de/pub/gentoo.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 oss apm arts avi crypt cups encode foomaticdb gif gpm gtk imlib jpeg kde gnome libg++ mad mikmod motif mpeg oggvorbis opengl pdflib png quicktime sdl spell svga truetype xml2 xmms xv zlib gdbm slang readline libwww perl python nptl threads sse mmx apache2 fam gd javascript justify maildir php pnp sasl usb x509 java ipv6 tcpd pam ssl -nls -X -qt xml ncurses berkdb"
BDB rears it ugly head again ;-) I realize this is a bug, for sure, but I should also mention to you that the virtual user features of pure-ftpd are better than the pam_userdb.so/vsftpd solution. You'd probably enjoy pure-ftpd much much more than what you're getting into with vsftpd. CC'ing Paul as he's pretty up on BDB link/symbol issues.
Chip, note the version kernel, glibc, gcc and then the 'nptl' in USE ;)
@Donny Gentoo is about choice isn't it? Personally I find vsftpd the best all around solution for my needs. I've tried pure-ftp after reading about how good it was in the forums and decided that I didn't like it. @Martin Given that there's a few people with this problem, I doubt that running the latest glibc, gcc, bison and kernel affect this one. I just happened to be the sucker reporting it :p However, I may be wrong..... BTWW, this also happens after compiling against the latest db (4.1.??) in the ~x86 branch - just get a 4001 error instead of 4000
As a sidenote, shouldn't vsftpd depend on virtual/inetd, not on xinetd
You should actually ask Donny as he worked with later PAM, but with NPTL, DB links against libpthread, which hinders dlopen to load pam_userdb.so ....
Fair enough. However, my understanding is that NPTL is now in the main branch of glibc so any NPTL bugs should be resovled sooner rather than later.
They are worked on: http://dev.gentoo.org/~woodchip/pam/
I am having this problem as well, on 2.4.22. Argh...aggrivating :/
I asked around in #gentoo to see if someone could help me with this, and they did, it took a while but after compiling manually with db4 it fixed the problem. I am no major Linux guru so excuse my lack of thoroughness, but I guess gentoo doesn't link to the db properly... after compiling with it linking properly and putting it in on my system, I am now able to run vsftpd.
okay, I just got this on an x86 (2.4 +grsec) system with USE="-nptl" # ldd /lib/security/pam_userdb.so libdb-3.2.so => /usr/lib/libdb-3.2.so (0x2646c000) libc.so.6 => /lib/libc.so.6 (0x264ef000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x119c5000) # ldd /usr/lib/libdb-3.2.so libc.so.6 => /lib/libc.so.6 (0x25d84000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0cf1e000) together with this, perhaps : http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43979 http://cvs.sourceforge.net/viewcvs.py/pam/Linux-PAM/modules/pam_userdb/Makefile.diff?r1=1.3&r2=1.4
okay, topping this off I tried ~x86 pam. Things went prettier from there: PAM unable to dlopen(/lib/security/pam_userdb.so) PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: dbm_firstkey] PAM adding faulty module: /lib/security/pam_userdb.so # ldd /lib/security/pam_userdb.so libc.so.6 => /lib/libc.so.6 (0x2f182000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x16531000)
There is a bug in the Pam-0.75-r11 ebuild script. Pam will use either db or ndbm but by default it prefers ndbm. Since there is no way to specify which one you want in the pam configure script, the ebuild munges the configure output. Unfortunately, it only munges the Make.rules file and overlooks _pam_aconf.h (HAVE_NDBM_H). As it stands the module is compiled with one set of headers and linked against the other library. Downloading pam and manually editing the configure output will produce a valid pam_userdb.so file.
i am seeing the same errors as spider in comment #11. this is after upgrading pam to 0.77 which pulled in db 4.1.25. everything was running just fine with db 3.2.9 and pam-0.75-r11. just like the reporter, i was using pam_userdb to support virtual users with vsftpd. please do not make me switch to pureftpd. running aa-sources 2.4.23-aa1, no nptl.
I am getting the same error as reported by Spider. 2.4.24-grsec-1.9.13-r1 no nptl Any movement on a solution?
So, what changes need to be made to get pam to build properly for bdb? Can I use the unpack, compile, install and qmerge ebuild commands in order to maintain consistency? In the _pam_aconf.h do I comment out the HAVE_NDBM_H or replace it with something?
Adding the following to line 196 in pam-0.77.ebuild solves it for me (db 4.1.25_p1-r3 and pam 0.77): sed -i -e "s:^#define HAVE_NDBM_H 1:#undef HAVE_NDBM_H:" _pam_aconf.h (Sorry, no patch. I haven't figured out how to make one yet ;))
What's the status here? No activity for over a year...
bug is still on if we mis-match db versions in various layers. A bit cleaner now that the defaults have changed for major installs. This bug is still triggable, but not as commonly due to obsolesence. Will trigger again with the next update, most probably.
(In reply to comment #18) > bug is still on if we mis-match db versions in various layers. > A bit cleaner now that the defaults have changed for major installs. > This bug is still triggable, but not as commonly due to obsolesence. > Will trigger again with the next update, most probably. It doesn't work. After an emerge World I ended up with pam-0.78-r3. The virtual users in vsftpd couldn't login anymore. Studying the pam ebuild, it appears that PAM compiles and links it's own version of Berkeley DB, in this case 4.3.27 which happens to be hard masked in portage. Well, I decided to take a chance and build Berkeley DB from the 4.3.27 ebuild. After that I recreated the vsftpd userdb using the db4.3_load tool, but it didn't make any difference. The pam_userdb module still doesn't work. I backed out PAM to pam-0.77-r6 and it works again. Guys, there is a serious problem in the pam_userdb module. I'm at a loss though. Regards, Toon.
are you certain this is the same bug, as in the missing symbols? if not, recent pam has a bug in userdb code that requires you to specify the crypt= setting, check the usedb readme.
Is this still an issue with 0.78?
This isn't going anywhere. If you can reproduce this w/ sys-auth/pam_userdb (yes it's a separate package now) and current ~arch PAM, reopen this bug.
