userlist options doesn't work in vsftpd

Bug #254687 reported by Eugene86
10
Affects Status Importance Assigned to Milestone
vsftpd (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: vsftpd

userlist options doesn't work in vsftpd in Hardy 8.04. anonymous user can't login despite it has been listed in userlist_file (userlist_deny=NO userlist_enable=YES) See example.
This configuration worked well in Gutsy 7.10
Also I can't found any way to return the old behaviour (only enlisted in userlist_file users can login)

Sample vsftpd.conf file:

anonymous_enable=YES
pam_service_name=vsftpd
secure_chroot_dir=/var/run/vsftpd
xferlog_enable=YES
dirmessage_enable=YES
listen=YES
userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd/user_list

Sample /etc/vsftpd/user_list file:
anonymous

Results of work:
$ ftp localhost
Connected to localhost.
220 (vsFTPd 2.0.6)
Name (localhost:seppel): anonymous
530 Permission denied.
Login failed.

Revision history for this message
toggy (tommy-tognella) wrote :

what I discoverd is that vsfpt seems to parse not all user_list file , but just the second half of the file.

What i did is copy and paste users twice in user_list file and it worked

Revision history for this message
Chuck Short (zulcss) wrote :

Marking as fixed released then.

Regards
chuck

Changed in vsftpd (Ubuntu):
status: New → Fix Released
Chuck Short (zulcss)
Changed in vsftpd (Ubuntu):
status: Fix Released → Confirmed
Thierry Carrez (ttx)
Changed in vsftpd (Ubuntu):
importance: Undecided → Low
Revision history for this message
Rolf Leggewie (r0lf) wrote :

Is this still an issue in 2024?

Changed in vsftpd (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Athos Ribeiro (athos-ribeiro) wrote :

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 address hidden>.
...

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 address hidden> or <email address hidden>) for transparency.

Changed in vsftpd (Ubuntu):
status: Incomplete → Triaged
importance: Low → Medium
tags: added: server-todo
tags: added: server-triage-discuss
removed: server-todo
tags: removed: server-triage-discuss
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.