Description of problem: deny_file seems to not work Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1.try using deny_file to prevent local users accessing /etc/passwd or eg /bin /var etc 2. 3. Actual results: failure Expected results: it should work Additional info: the following fail to prevent /etc/passwd from being fetched: deny_file=/etc/passwd deny_file=/etc/* deny_file=passwd
I've followed your instructions and this seems to work as it's supposed to # cat /etc/vsftpd/vsftpd.conf | grep deny_file deny_file=/etc/passwd deny_file=/etc/* deny_file=passwd $ ftp localhost Connected to localhost.localdomain. 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /etc/ 250 Directory successfully changed. ftp> get passwd local: passwd remote: passwd 227 Entering Passive Mode (127,0,0,1,119,140) 550 Permission denied. commenting those deny_file lines, restarting the server and the result is $ ftp localhost Connected to localhost.localdomain. 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /etc 250 Directory successfully changed. ftp> get passwd local: passwd remote: passwd 227 Entering Passive Mode (127,0,0,1,213,234) 150 Opening BINARY mode data connection for passwd (3118 bytes). 226 File send OK. 3118 bytes received in 0.00017 seconds (1.8e+04 Kbytes/s) ftp> May I have your whole vsftpd.conf file. Also check man vsftpd.conf, there might be some options which overlaps deny_file.
no no, you misunderstand. you would expect any one of those deny_file lines _on its own_ to prevent fetching the file. for example you would expect deny_file=/etc/* on its own to prevent fetching any file from /etc/, but this is not what happens. you would expect deny_file=/etc/passwd to prevent fetching /etc/passwd, but this is not what happens.
aha, I'm kinda slow this mornig :) You're correct, those expressions should work but they are somehow funky (I've tried accessing the files with mc and rule /etc/* worked ok, but with good old ftp I can still get /etc/passwd). Well the regular expressions in vsftpd are very limited and as man page says, you have to be carefull setting up the rules and test them .. which is nice excuse :) .. I will try to do some rework.
my guess is mc uses full paths all the time when fetching files, while other ftp clients do not (they fetch the file relative to cwd), and vsftpd is only matching patterns given on the commandline, not matching vs the full file paths.
I've looked into the code and the comparission for deny_file is basically correct. It's rather a simple one, so in this case or in any case of blocking the content of whole directory I recommend using deny_file=/etc* (not additional slash) This rule blocks changing directory to /etc (with the old rule, this was possible due to rule /etc/* which doesn't evalute /etc as prohibited) and also blocks downloading the content of /etc directory. I'm closing this bug as NOTABUG. Maybe there should be feature requet to upstream to swith over to regular expressions, like fnmatch() has.
please tell me you do not actually deliberately intend the following to work... # tail /etc/vsftpd/vsftpd.conf # sites. However, some broken FTP clients such as "ncftp" and "mirror" assume # the presence of the "-R" option, so there is a strong case for enabling it. #ls_recurse_enable=YES pam_service_name=vsftpd userlist_enable=YES #enable for standalone mode listen=YES tcp_wrappers=YES deny_file=/etc* $ ftp localhost Connected to localhost.localdomain. 220 (vsFTPd 2.0.3) 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type Name (localhost:goemon): goemon 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd / 250 Directory successfully changed. ftp> cd /etc 550 Permission denied. ftp> cd etc 250 Directory successfully changed. ftp> get passwd local: passwd remote: passwd 227 Entering Passive Mode (127,0,0,1,99,251) 150 Opening BINARY mode data connection for passwd (2813 bytes). 226 File send OK. 2813 bytes received in 0.00016 seconds (1.7e+04 Kbytes/s) ftp> quit 221 Goodbye. NOTABUG? seriously?
You're right. That's pretty crappy. But you see that obviosly in the second case the rule won't match `cd etc`. I still don't classify this as a bug but as a feature request for futher rework.
Created attachment 134552 [details] This patch adds a new function str_basename() and makes the filename filter smarter :]
(In reply to comment #0) ... > Additional info: > the following fail to prevent /etc/passwd from being fetched: > deny_file=/etc/passwd > deny_file=/etc/* > deny_file=passwd There can't be 3 lines of deny_file option. If you need deny this values, you need use : deny_file={/etc/passwd,/etc/*,passwd} The patch resolved '/etc | etc' problem and it's attached in RAWHIDE.
there isnt three lines of deny_file option. my point was _any of those lines on their own_ failed to prevent /etc/passwd from being fetched. that is to say: deny_file=/etc/passwd OR deny_file=/etc/* OR deny_file=passwd utterly failed preventing someone from fetching /etc/passwd via ftp.
So, in that case it's true. I thing, patch works fine and we could leave the bug as closed. If any new bugs in this filter, please reopen it.