vsftpd no longer supports both anonymous_enable and local_enable

> Setting anonymous_enable to YES enables identified login (aknaff), but (obviously) disables anonymous (ftp) login

Unless I am very confused, the YES in that final sentence in the bug description was probably intended to be NO :)

Indeed. Sorry for the confusion

Setting both of the options works for 2.3.0 in Maverick, i.e. you can login anon or with a specified username and password.

Unable to reproduce on up-to-date lucid either; both anon and normal logins still work after reconfiguration.

Alain

Have you changed any other vsftpd configuration? If so a copy of /etc/vsftpd.conf would be really helpful to diagnose this issue further.

Thanks

Setting back to New status because bug submitter kindly supplied the requested vsftpd.conf

Unable to reproduce with the configuration file supplied.

Alain - please could you also attach the following files and output:

  /var/log/vsftpd.log
  grep vsftpd /var/log/auth.log

Thanks

It seems to complain about pam_shells.

And indeed, after commenting this out, the problem goes away, even with both anonymous_enable and local_enable set to YES.

The problem becomes different when starting vsftpd from the command line instead of using "service vsftpd start":

# ftp localhost
Connected to localhost.localdomain.
220 (vsFTPd 2.2.2)
Name (localhost:root): aknaff
331 Please specify the password.
Password:
ltdb: tdb(/var/lib/samba/group_mapping.ldb): tdb_mmap failed for size 77824 (Cannot allocate memory)
Login failed.

Another weird thing is that the process spawned by vsftpd.log per user has the following in /proc/<pid>/limits

Max address space 104857600 104857600 bytes

The master process doesn't, it has:

Max address space unlimited unlimited bytes

[Expired for vsftpd (Ubuntu) because there has been no activity for 60 days.]

Alain, first, thanks for responding and working with us to try and nail down this issue.

vsftpd is run via an upstart job when you start it with 'service vsftpd start'. This means it will be a direct child of pid 1, and not be subject to any of the limits you may have imposed on your login shell. I'd say that starting it manually isn't really a supported way to start vsftpd.

Do you get the errors about pam_shells if you start with 'service vsftpd start', or only when starting it manually?

Marking Incomplete again, pending response from Alain. My guess is that there's no bug, just poor documentation on best practices for daemons that are setup to be managed via upstart.

The problem with pam_shells and local_enable+anonymous_enable occurs when starting vsftpd via 'service vsftpd start'.

The only reason why I mentioned starting it "manually" at all was because that is what I did to more precisely trace the issue.

[Expired for vsftpd (Ubuntu) because there has been no activity for 60 days.]

Re-tested on Ubuntu 10.04.2 LTS, vsftpd 2.2.2-3ubuntu6.2

==> Bug still present

This bug was (accidentally?) marked as a duplicate of an unrelated bug (certificates, whereas this one is about anonymous ftp). How can we undo this?

Thanks

Clicking the little edit icon next to the duplicate number and blanking out the 'duplicate of' number field removes the duplicate relationship. I think any logged in user can do this, although you might need a certain amount of karma.

Workaround: disable winbind authentication in pam-auth-update. There seems to be a conflict between samba winbind and vsftp's pam modules.

Clarification: smbpasswd-migrate not winbind

After disabling this in /usr/share/pam-configs/smbpasswd-migrate, it does indeed work now. Thanks.

Since I disabled smbpasswd-migrate, I now get the following in my auth.log

Oct 15 09:45:28 crmm vsftpd: PAM unable to dlopen(/lib/security/pam_smbpass.so): libgpg-error.so.0: failed to map segment from shared object: Cannot allocate memory
Oct 15 09:45:28 crmm vsftpd: PAM adding faulty module: /lib/security/pam_smbpass.so

Despite these messages, login of both anonymous and local users succeeds however.

Remove the package libpam-smbpass altogether makes the messages disappear, however we need libpam-smbpass for other reasons. Any ideas?

Interestingly enough, the message also goes away when disabling blowfish authentication while still keeping libpam-smbpass around.

I've found out that this bug (and it is of cause a BUG) doesn't show up if all configs for vsftpd are straight:
if shell is nologin, it should be /usr/sbin/nologin in /etc/passwd, it should be mentioned also in /etc/shells, etc.