Bug 842462 - vsftpd upload returns 550 Permission denied starting with 2.0.5-24
vsftpd upload returns 550 Permission denied starting with 2.0.5-24
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vsftpd (Show other bugs)
5.8
Unspecified Linux
unspecified Severity medium
: rc
: ---
Assigned To: Jiri Skala
BaseOS QE Security Team
: EasyFix, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-23 18:41 EDT by Brian Carp
Modified: 2014-11-09 17:35 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-02 09:15:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The patch fixes complained issue (869 bytes, patch)
2013-04-24 05:47 EDT, Jiri Skala
no flags Details | Diff

  None (edit)
Description Brian Carp 2012-07-23 18:41:31 EDT
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.
Comment 1 Jiri Skala 2012-07-24 03:22:49 EDT
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
Comment 2 Brian Carp 2012-07-24 11:59:20 EDT
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).
Comment 3 Joe Zeff 2013-04-07 22:01:51 EDT
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.
Comment 4 Joe Zeff 2013-04-07 22:19:52 EDT
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
Comment 5 Jiri Skala 2013-04-08 09:41:37 EDT
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.
Comment 6 Brian Carp 2013-04-08 11:49:43 EDT
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.
Comment 7 Brian Carp 2013-04-08 12:08:10 EDT
(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.
Comment 8 Jiri Skala 2013-04-24 05:47:13 EDT
Created attachment 739371 [details]
The patch fixes complained issue
Comment 9 RHEL Product and Program Management 2013-05-01 02:52:49 EDT
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.
Comment 10 RHEL Product and Program Management 2014-03-07 07:46:13 EST
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.
Comment 11 RHEL Product and Program Management 2014-06-02 09:15:59 EDT
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).
Comment 12 Brian Carp 2014-06-17 19:32:04 EDT
That's very sad, considering this was an easy fix with a small patch.

Why was this tagged NEEDINFO? What information does it need?
Comment 13 Ondrej Vasik 2014-06-18 07:05:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.