I have a problem with vsftpd on Debian: I can upload files if the chmod of all folders is 777, but with chmod 755.
Please help.
vsftpd.conf:
local_umask=022
anon_umask=0755
file_open_mode=0755
chmoddebianftplinuxvsftpd
I have a problem with vsftpd on Debian: I can upload files if the chmod of all folders is 777, but with chmod 755.
Please help.
vsftpd.conf:
local_umask=022
anon_umask=0755
file_open_mode=0755
First of all a minor terminology nitpick: chmod
doesn't remove permissions. It CHANGES them.
Now the meat of the issue -- The mode 777
means "Anyone can read, write or execute this file" - You have given permission for anyone to do (effectively) whatever the heck they want.
Now, why is this bad?
login
program that lets them in every time).rm -r /
and it's all over. The OS was told to let them do whatever they wanted!sudo
, sendmail
, and a host of others simply will not start any more. They will examine key file permissions, see they're not what they're supposed to be, and kick back an error message.ssh
will break horribly (key files must have specific permissions, otherwise they're "insecure" and by default SSH will refuse to use them.)777
is actually 0
777
. Among the things in that leading digit are the setuid
and setgid
bits./tmp
and /var/tmp
The other thing in that leading octal digit that got zero'd is the sticky bit
-- That which protects files in /tmp
(and /var/tmp
) from being deleted by people who don't own them.rm -r /tmp/*
, and without the sticky bit set on /tmp
you can kiss all the files in that directory goodbye./dev
/proc
and similar filesystems/dev
is a real filesystem, and the stuff it contains are special files created with mknod
, as the permissions change will be preserved across reboots, but on any system having your device permissions changing can cause substantial problems, from the obvious security risks (everyone can read every TTY) to the less-obvious potential causes of a kernel panic.Credit to @Tonny for pointing out this possibility
Credit to @Tonny for pointing out this possibility
.
in their PATH
environment variable (you shouldn't!) - This could cause an unpleasant surprise as now anyone can drop a file conveniently named like a command (say make
or ls
, and have a shot at getting you to run their malicious code.Credit to @RichHomolka for pointing out this possibility
chmod
will reset Access Control Lists (ACLs)Credit to @JamesYoungman for pointing out this possibility
Will the parts of the system which are already running continue to run? Probably, for a while at least.
But the next time you need to launch a program, or restart a service, or heaven forbid REBOOT the box you're in for a world of hurt as #2 and #3 above will rear their ugly heads.
It looks like you're trying to use active FTP, but a firewall between the server and (or on) your client is blocking the data channel. An FTP transaction consists of two channels, or connections: the command channel (on port 21) and the data channel (usually associated with port 20). The client issues commands on the command channel, while the payload (file contents and output of commands like ls
) goes on the data channel. If you've got a firewall or router interfering with the data channel, you can log in and everything will appear to work until you try to get or send information to/from the server - at which point everything will appear to just hang. The server's trying to connect back to the client, but it's not able to do so.
In active mode (the default unless you send the PASV
command [and note that vsftpd is suggesting that you Consider using PASV
]), the server attempts to open a connection to the client for the data channel. That's right - the server is connecting back to the client, and on a port greater than 1023. Firewalls tend to object to this, and if you're behind NAT, it just can't work at all.
This is where passive FTP comes in. With passive FTP, the server uses the established connamd channel to tell the client what port and IP address to use for the data channel, and then the client opens a second connection to the server for the data channel. This solves the problem of the client being behind a firewall. All that you need to do is issue the PASV
command from the client before the PUT
. If that doesn't work, then you may need to help vsftpd a little bit. Configuration items you may want include pasv_min_port
and pasv_max_port
, which let you control a range of ports vsftpd tells the client to connect to, so you can open them in your firewall. Also, if the server isn't listening on the same IP address that the client is connecting to (inside a NAT, perhaps), pasv_address
tells vsftp where the client actually wants to connect to (it won't automatically use the address the command channel is opened on).
Best Answer
Sounds like the user you're logging in as has no ownership rights of the folder you're accessing.
FWIW 777 isn't neccessary as you don't need execute (just read/write)
You could possibly put the ftp user in the same group as the owner then
chmod g+rw
or you couldchown -R ftpfolder ftpuser.ftpuser
but consider the potential implications of other users that may need access.