Ftp Chmod 755

It's really inappropriate to be running FTP over the public Internet.

I understand the risks thanks

anyone else

What do you mena by "currently proftpd wont allow 755 permissions. "? Error messages, logs …

for security reasons proftpd doesnt allow uploaded files to be chmod 755 only directories.

I guess im looking for a solution to allow Two users to be able to upload to one directory without conflicts.

if anyone has an example of vsftpd or proftpd that use's multiple users I'd be interested in seeing their config files

Thats because the 1 bit means "execute". Directories need execute permissions to be entered. Files need execute permissions to be executed. If proftpd allowed files to be executable, it might allow for arbitrary code execution.

I'd suggest understanding what the 7 and 5 in '755' mean, and then applying that knowledge to the files you're trying to upload.

And your response to Xan concerns me… DO you actually understand the risks? Assuming you're using the system users for proftpd, you do realize you're sending the system passwords in the clear over the internet? The same passwords that could then be used to log into your node?

@mwalling:

Thats because the 1 bit means "execute". Directories need execute permissions to be entered. Files need execute permissions to be executed. If proftpd allowed files to be executable, it might allow for arbitrary code execution.

I'd suggest understanding what the 7 and 5 in '755' mean, and then applying that knowledge to the files you're trying to upload.

And your response to Xan concerns me… DO you actually understand the risks? Assuming you're using the system users for proftpd, you do realize you're sending the system passwords in the clear over the internet? The same passwords that could then be used to log into your node?

Agreed I understand the risks because whats going in the Ftp directory is not important and not for web usage and not accessible by any other source to the outside world etc… also it has disk space limitations etc.. etc.. even if it was compromised i have a script that checks which IP logged in.

I just need the ability for each user to share a directory, I was hoping adding them both to the same group would allow this but not such luck with the restrictive permission settings

It sounds like it will work, but as mwalling said, you need to examine the need for the execute bit on your files.

@Xan:

It sounds like it will work, but as mwalling said, you need to examine the need for the execute bit on your files.
Ok well I don't need execute I just need both users ability to share one set of files / directories

If you don't need the execute bit, why are you setting it?

You don't seem to understand the risks here. It's not about the security that you've set up around your FTP server, it's that the user passwords will be vulnerable to interception. At that point, your FTP security is irrelevant, because the attacker can get in via SSH or any other protocol exposed by your server; they have the passwords.

There are very few legitimate reasons to be running plain FTP in this day and age. It's strongly recommended that you use SFTP/SCP instead.

The only reason anyone besides a braindead shared host would run plain FTP is anonymous FTP. But maybe that will do what the OP wants?

Or if you want to forgo all the advice given above, let the two users log in with the same ID/password and hence upload to the same account's home directory. I mean, if they're going to share the same directory and all the same files, what's the point of keeping one user's password secret to the other?

Read up on UNIX permissions:

http://www.zzee.com/solutions/unix-permissions.shtml

The best way to do it, put both users in the same group, then give the files/directories group write access. You'll also need to make sure the files/directories are owned by said group.

Running FTP over the internet with cleartext passwords is sorta okay, as long as you're not using system accounts for your FTP logins. Last I checked, ProFTPd allows you to use the system accounts, or store the info in files or a SQL database.

This would be okay, provided the passwords used for these users are not the same as any other passwords.

However, passwords in cleartext is a bad idea.

Just preventing the system account from logging in via FTP is hardly sufficient. Imagine this scenario:

1) RegularUser logs in to FTP via public wifi

2) RegularUser's password is sniffed

3) EvilDude SSHs to your box

4) EvilDude runs a kernel root exploit

5) EvilDude changes your root password and has fun erasing/stealing your data and hosting up all sorts of nasty things

The only way to prevent this scenario is to not allow cleartext password authentication by NOT running FTP…

@Guspaz:

Just preventing the system account from logging in via FTP is hardly sufficient.

He said not using system accounts. ie, the FTP server only uses it's own accounts. So that #3 in your scenario isn't possible.

Guspaz,

The suggestion wasn't to disable access to the "System" account (which should go without saying), but to have FTP logins that are completely separate from other logins in the system (like SSH).

Edit: bah! glg beat me to it. :-)

True. That, of course, doesn't preclude the possibility of an FTP server exploit that might be made easier by the attacker having access to an FTP account. But does mitigate a lot of the risk.

I'd still urge that FTP is just a bad protocol to use in general, though; protocols that use cleartext authentication have no place on the net.

Agreed.

@Guspaz:

I'd still urge that FTP is just a bad protocol to use in general, though; protocols that use cleartext authentication have no place on the net.

no question. scp/sftp are just as easy to use