I was able to reproduce the described behavior in noble by using the provided configuration files and running
$ ftp -a localhost Connected to localhost. 220 (vsFTPd 3.0.5) 530 Permission denied. ftp: Login failed Then, checking the manpage for vsftpd.conf, I see: local_enable Controls whether local logins are permitted or not. If enabled, normal user accounts in /etc/passwd (or wherever your PAM config references) may be used to log in. This must be enable for any non-anonymous login to work, including virtual users. Default: NO and ftp_username This is the name of the user we use for handling anonymous FTP. The home directory of this user is the root of the anonymous FTP area. Default: ftp I then tried appending local_enable=YES to the configuration file provided by the reporter and could then successfully login [ftp] OK LOGIN: Client "127.0.0.1", anon password "?" Then, if I remove the "anonymous" entry from /etc/vsftpd/user_list, I can no longer login. Until here, this looked like a documentation issue for the local_enable option given the "anonymous" user actually logs in as the local "ftp" user. However, I kept experimenting with the provided configuration file, and found that when I remove the userlist_deny=NO entry, the anonymous user can always login regardless of the contents of /etc/vsftpd/user_list, i.e., it doesn't matter if "anonymous" or "ftp" are in this list or not, anonymous login attempts always succeed. At this point, I was actually expecting the behavior to be consistent and keep respecting the list with the userlist_enable described behavior (i.e., names in the list cannot login). Finally, since the original bug was reported for Ubuntu 8.04 (shipping vsftpd 2.0.6) and mentions that the behavior was different in Ubuntu 7.10 (shipping vsftpd 2.0.5), I checked the upstream changelogs and found the following entry: Changelog for 2.0.6: ... - Fix bug with empty user list file and userlist_deny=NO. Reported by +Marcin Zawadzki/GlobalVanet.com <[email protected]>. ... Which is may potentially be the change which caused the regression with the anonymous login behavior. Now, thinking on an approach on how to get this fixed: - we do have vsftpd 3.0.5 in noble, which is the latest version, and, as per the analysis above, is still affected. - the bug seems to be around for more than 15 years and I could not find other reports similar to this one around - this may be an evidence that this specific use case is not that popular at all. - but: AFAIU, there is no upstream VCS or bug tracker. With this in mind, I believe a good path forward here would be to report the issue to the upstream maintainer (there is a contact email in the upstream project page) to ensure this is indeed a bug and discuss a possible fix here. I also wonder if the email should Cc a mailing list (e.g., [email protected] or ubuntu-devel- [email protected]) for transparency. ** Changed in: vsftpd (Ubuntu) Status: Incomplete => Triaged ** Changed in: vsftpd (Ubuntu) Importance: Low => Medium ** Tags added: server-todo ** Tags removed: server-todo ** Tags added: server-triage-discuss -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/254687 Title: userlist options doesn't work in vsftpd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/254687/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
