You are not logged in.
Having a bit of trouble setting up vsftpd with virtual users here. After creating the configuration file and db file for PAM authentication, I fire up vsftpd and try to log on using the virtual usernames and passwords. The result is a failed login attempt, and some errors show up in /var/log/vsftpd.log and /var/log/errors.log.
Here's what I've got in the way of configs and PAM files. Note that /etc/hosts.allow has an entry to allow all vsftpd traffic.
/etc/vsftpd.conf
anonymous_enable=NO
local_enable=YES
write_enable=NO
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
chroot_local_user=YES
guest_enable=YES
guest_username=ftp
listen=YES
listen_port=21
pasv_min_port=50000
pasv_max_port=50100
anon_world_readable_only=NO
xferlog_enable=YES/etc/pam.d/ftp (has same ownership/permissions as rest of pam modules)
auth required /lib/security/pam_userdb.so db=/etc/vsftpd_login
account required /lib/secutiry/pam_userdb.so db=/etc/vsftpd_login/etc/vsftpd_login.txt
user1
pass1
user2
pass2…combined with
[root@server etc]# db_load –T –t hash –f vsftpd_login.txt vsftpd_login.db
[root@server etc]# chmod 600 vsftpd_login.dbThe following log excerpts are the result of several login attempts (the two virtual users and an actual system user). I used the standard ftp://user1:pass1@ XXX.XXX.XXX.XXX to connect.
In /var/log/vsftpd.log
Fri Sep 17 10:31:19 2004 [pid 3585] CONNECT: Client "XXX.XXX.XXX.XXX"
Fri Sep 17 10:31:20 2004 [pid 3584] [user1] FAIL LOGIN: Client "XXX.XXX.XXX.XXX"In /var/log/auth.log
Sep 17 10:31:20 server vsftpd: PAM unable to dlopen(/lib/security/pam_userdb.so)
Sep 17 10:31:20 server vsftpd: PAM [dlerror: /lib/security/pam_userdb.so: undefined symbol: dbm_open]
Sep 17 10:31:20 server vsftpd: PAM adding faulty module: /lib/security/pam_userdb.so
Sep 17 10:31:20 server vsftpd: PAM unable to dlopen(/lib/secutiry/pam_userdb.so)
Sep 17 10:31:20 server vsftpd: PAM [dlerror: /lib/secutiry/pam_userdb.so: cannot open shared object file: No such file]
Sep 17 10:31:20 server vsftpd: PAM adding faulty module: /lib/secutiry/pam_userdb.soThe user2:pass2 virtual account and all system accounts produce identical entries.
If I remove or rename the PAM file /etc/pam.d/ftp, I can connect with system usernames and passwords with no problem at all.
I searched the net for "pam_userdb.so: undefined symbol: dbm_open" and got a lot of hits, but nothing that made much sense to me. I did see a Red Hat Bugzilla entry here; I ran the ldd command, got a similar result, but I'm not sure what it means (if anything)?
[root@server etc]# ldd -r /lib/security/pam_userdb.so
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0x40007000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
undefined symbol: dbm_open (/lib/security/pam_userdb.so)
undefined symbol: dbm_fetch (/lib/security/pam_userdb.so)
undefined symbol: dbm_close (/lib/security/pam_userdb.so)
undefined symbol: dbm_firstkey (/lib/security/pam_userdb.so)
undefined symbol: dbm_nextkey (/lib/security/pam_userdb.so)
undefined symbol: pam_get_user (/lib/security/pam_userdb.so)
undefined symbol: pam_get_item (/lib/security/pam_userdb.so)
undefined symbol: pam_set_item (/lib/security/pam_userdb.so)I'm open to any advice you can offer.
[EDIT] fixed broken link
Offline
I've done some research on this one, and this is my conclusion:
we need a newer version of our berkeley db, 4.X+, and then recompile PAM to use db4 instead of libndbm.
this will work, I hope.
Links:
http://forums.gentoo.org/viewtopic.php? … vsftpd+pam
This seem to be the most realistic solution.
I will try to do it this afternoon, if I can find the packages and everything ![]()
To err is human... to really foul up requires the root password.
Offline
Excellent. Can't wait to hear your results. ![]()
Offline
Any updates? I've searched some more, and found a couple of fixes that involve patching configure.in with modified AC_CHECK_LIB macros for db detection. Unfortunately, it's well beyond my abilities to generate a fix on my own, let alone understand what I'm reading.
Is a db upgrade really required? My current version is 4.2.52-1
Surely someone running vsftpd on Arch has run into this problem before and generated a fix?
Is this something that should be filed as a bug?
Offline