Description of problem: After upgrading to vsftpd-2.0.5-24.el5_8.1.i386, configurations with write_enable set to YES stopped allowing uploading, returning instead "550 Permission denied." Directory creation was still possible. Downgrading to vsftpd-2.0.5-21.el5.i386 fixes the problem, but nothing in the changelog indicates what might be causing the problem. Version-Release number of selected component (if applicable): 2.0.5-24.el5_8.1 Steps to Reproduce: 1. yum install vsftpd-2.0.5-24.el5_8.1 2. service vsftpd restart Actual results: "550 Permission denied." Expected results: "150 Ok to send data." Additional info: I did a full downgrade to the next highest minor version. I didn't try the intermediary vsftpd-2.0.5-24.el5.i386 because I assumed it wouldn't be a big enough difference.
Hi, 1. What's the user name of the client - local user or anonymous? 2. Please provide me an output of # grep '^[a-z]' /etc/vsftpd/vsftpd.conf 3. Please provide me an output of # getsebool -a | grep ftp 4. Check/provide me /var/log/messages. Any AVC? Thanks Jiri
1. The client is local user as guest (with guest_enable and guest_username), both in the instance of regular local users mapped to the guest user and also in another vsftpd instance using virtual users looked up in a separate database. 2. Contents of /etc/vsftpd/vsftpd.conf: anonymous_enable=NO local_enable=YES guest_enable=YES guest_username=guestftp write_enable=YES anon_umask=002 anon_upload_enable=YES anon_mkdir_write_enable=YES anon_other_write_enable=YES anon_world_readable_only=NO chroot_local_user=YES chmod_enable=NO hide_ids=YES use_localtime=YES max_per_ip=8 deny_file={.*,*.rdonly} hide_file={.*,*.hidden} dirmessage_enable=YES xferlog_enable=YES vsftpd_log_file=/var/log/vsftpd/vsftpd_log connect_from_port_20=NO pam_service_name=vsftpd userlist_enable=YES userlist_deny=NO userlist_file=/etc/vsftpd/user_list listen=YES tcp_wrappers=YES 3. SELinux is disabled (so, not a factor, I don't think) 4. Nothing appears in /var/log/messages Again, just to make it clear, same machine with same exact configuration, everything works fine with vsftpd-2.0.5-16 and vsftpd-2.0.5-21, but uploads fail with the "Permission denied" error when upgraded to vsftpd-2.0.5-24.el5_8.1 (and possibly vsftpd-2.0.5-24.el5 although I haven't tried it yet).
I just received the same error using vsftpd 3.0.0-2.fc17. I was trying to connect to my desktop from my laptop, in the same room, to transfer a file. Checking, the file /etc/vsftpd/vsftpd.conf is the sample file, with no changes that I'm aware of. And, I wasn't trying to log in as guest or anonymous, I was trying to log in as myself.
This just happened again, after I followed the SELinux instructions to create and install a module. I tried to report it through the trouble-shooter, but it found Bug 874536, which suggested this: setsebool -P ftp_home_dir 1
The issue seems to be introduced implementing square brackets in ls command. 'deny_file' option uses the same filtering function that is a source of difficulties - need more investigation. The issue vanishes away removing 'deny_file' from vsftpd.conf.
Yes, the deny_file and hide_file options are definitely the culprit. This version apparently treats ".*" as a wildcard -- maybe using regular expressions rather than shell expansion as the documentation indicates it should be. So I imagine "square brackets" are a related problem. The goal here for me was to block dot-files from user download/upload. How should this be done with the latest version? Does the documentation need updating? It's still not clear if this is a bug fix or a documentation fix.
(In reply to my own comment #6) Sorry, I was imprecise in describing this as "shell expansion". The man page documentation says the following for deny_file: "Note that vsftpd’s regular expression matching code is a simple implementation which is a subset of full regular expression functionality. Because of this, you will need to carefully and exhaustively test any application of this option. And you are recommended to use filesystem permissions for any important security policies due to their greater reliability. Supported regex syntax is any number of *, ? and unnested {,} operators. Regex matching is only supported on the last component of a path, e.g. a/b/? is supported but a/?/c is not. Example: deny_file={*.mp3,*.mov,.private}" While that's not totally clear, it does suggest that the only special characters are "*", "?" and "{,}" and that the period is not special; also the examples suggest that "*.mp3" would match "example.mp3" but not "amp3" or "anmp3". And it also suggests using the curly brackets in same manner as my posted config above. So, like I said, something's wrong: either a bug or the documentation in both the changelog and the man page.
Created attachment 739371 [details] The patch fixes complained issue
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).
That's very sad, considering this was an easy fix with a small patch. Why was this tagged NEEDINFO? What information does it need?
The information is in comment #10 - needinfo was primarily to ensure that high business priority requests were properly escalated. Unfortunately, capacity for the updates is always limited - and vsftpd has quite long history of asynchronous updates - thus is not suitable for the fastracks. That being sad, even the simple, easy fixes have to go through the prioritization and approval process. Sorry for that - even though, such bug reports are valuable - as engineers work with upstream and usually fix the issues for the next version of Red Hat Enterprise Linux.