joelf

[Log in to get rid of this advertisement]

I have VSFTP set up wonderfully on Redhat 9 Beta (Severn).
They improved its default config on this over the last version
(which wasn't a beta) and its almost 100%.


PROBLEM: I want users to be able to upload and download
but I absolutely do -not- want them to be able to DELETE!
Ideally, they can upload to the "upload" directory but thats
it. Currently, any of them can delete my files and I can not
seem to figure this out!


COMMENTARY: It seems to me that VSFTP is good but that its not
very flexable and that the distro guys need to fine tune it.
If you have an error in your config, VSFTP does not even send
any debug info the the /var/log/messages! Also, if you screw
around with PAM and VSFTP like I did on my last install, you
can just forget about VSFTP working again. I am sure I could
have figured out the problem but who has 16 days to dink
around with this crap? Meanwhile, microsoft OS guys are
setting up their lame FTP servers in 5 minutes. Doesnt look
good for us. ;-) I am sure the RH guys have a reason for
the VSFTP config but it is not correct for me and it will not
easily do what I want/need it to do.


/etc/vsftpd/vsftpd.conf
# Example config file /etc/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=YES
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
# write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
#connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
nopriv_user=ftp
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that turning on ascii_download_enable enables malicious remote parties
# to consume your I/O resources, by issuing the command "SIZE /big/file" in
# ASCII mode.
# These ASCII options are split into upload and download because you may wish
# to enable ASCII uploads (to prevent uploaded scripts etc. from breaking),
# without the DoS risk of SIZE and ASCII downloads. ASCII mangling should be
# on the client anyway..
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd.banned_emails
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd.chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# 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

connect_from_port_20=NO
# My ghey ISP blocks all <1024 ports.
listen_port=3000
max_clients=4
banner_file=/etc/vsftp.banner
hide_ids=YES

local_enable=YES
local_max_rate=256000

# Tried to allow anon users to have upload/download and no delete
# but it would not config right so now we're going for local users.
anon_root=/storage/public
anon_max_rate=256000
anon_upload_enable=NO
anon_world_readable_only=YES
anonymous_enable=NO

local_enable=YES
# For passwd_chroot_enable, users jail location is in /etc/passwd
passwd_chroot_enable=YES
chroot_local_user=YES
chroot_list_enable=YES
# This allows operations like DELETE but I do not want the users
# to have that ability! I only want them to be able to upload/download.
write_enable=YES

cyberskye

Think about file permissions. The directory must be read/write for any user, yes?

Describe how peeps will use this - is this a way for two remote users to trade files or a way for folks to send you stuff.

If the former, I might set up a webserver and use php to manage file upload and permissions. This way you would have finite control over access - and could even automatically dump copies of files to some other location inaccessible to the users as an archive.

Cheers,

Skye

joelf

Ok, first of all, thats cool about the PHP and web server.
The problem is that Apache is great but difficult for me to
configure and PHP- wow, dont get me started. I really
am not equiped upstairs for PHP at this time. FTP, I
understand.

Down the road, I am interested in doing things the
way that you mentioned but for now, I need FTP to work
correctly.

CORRECTLY MEANING: I need users to log in and download
files without being able to delete. I need users to log in
to upload into a specific folder ONLY with no delete OR
to be able to delete only their stuff (But not necessary).

Also, I have a ton of files and if I want certain users to
have access to certain files, I can not just place the
respective files in their home folders- I do not have the
disk space. This server is FULL of stuff. I have various
folders of MP3s, Movies, Software, etc for my friends
and myself to be able to access. I didnt want to move
them around really.

Looking into the VSFTP source, I can see other "tunable"
features- if nobody can answer me here, I am going to
see if I can write something into the code or play with
the other tunables that are not widely known to fix
the problem. *grumble* ;-)

Anyhow, thanks for the reply. Let me know if you have
any ideas for the config OR how to easily set up what
you were talking about. =)

Joel

cyberskye

That's pretty tough to do - from my toolbox anyway.

I suggested php because the only way I know to do this safely would require a clean-up script run and move the files (and change permissions) after the upload. Especially since you have anonymous enabled.

You could play with the umask setting and just make everything 444, but not sure if that will give you what you want -

Will users have a central repository or home directories as well? Access to each others' directories?

gasman2

cyberskye is correct. You should work on enforcing what you want with permissions on the directories/files. Look into setting the sticky bit on the dir (immutable bit). You could also setup a dir so users can write files, yet not see what is in the dir, and make it immutable.

joelf

Back to the FTP at hand.

Ok, I am using the RH9.x beta so there could be some bugs
that I will not be able to fix but assume that their are not,
I am going to keep trying to config VSFTP like planned. Its
one of the best FTP daemons (if not the best) and I think
its workable. There are some not-so-documented tunables
and I am going to try to mess with that.

I am going to try to get VSFTP to run as another user
instead of ROOT to begin with.

unSpawn

First of all I'm not familiar with the lastest greatest version of Vsftp, so I can't comment on the new directives. From you config I see you got a lot of duplicate directives so first of all you should be cleaning up.

I think what you want should be in the doc/example/virtual users subdirs. Throw out all the anon stuff and set up a virtual user. This makes everyone share the same ftp root. The problem is write operations. Allowing writes is a security risk and a good way to see if you can exploit a FTP server. And deleting is a write op too. Write ops are operations on the inode list of the dir the files reside in. So, if you need to allow writes in the sense of uploads, then you're by default allowing writes in the sense of deletion too. Chowning uploaded files to a different user makes files undeletable by the uploader provided the umask is sanely set to 022 and the dir isn't world writable either.

Simple test:
umask 077; mkdir -p /tmp/1/2/3; chown 0500 /tmp/1/2
rm -rf /tmp/1/2/3 # "Permission denied"
touch /tmp/1/2/3/4 && shred /tmp/1/2/3/4 # succeeded
rm -rf /tmp/1 # Got "Permission denied" for /tmp/1 and all subdirs.
chmod 0700 -R /tmp/1 && rm -rf /tmp/1 # succeeded

Of course it is best practice not to allow writes, but if you have to, then at least make sure they're writable by an unprivileged user without write (no read would be cool too) access to the rest of the filesystem. Make sure all dirs and files in the ftp root except uploaddir have unset write bit, and if you're running ext2/3 then using the immutable bit on all dirs and files in the ftp root except uploaddir will make sure they're unchangable even if you fsck up the permissons. Another way could be to have the upload dir on a partition mounted writable but not suid,exec, and the other dirs bound from a readonly partition.


I prefer running Muddleftpd as I don't mind trading in flexibility for working with multiple config files (doesn't imply I'm one of Dan Bernstein's disciples). It's main config is rather sparse, but I get user groupings, per-group configs, per-user configs, per-config access restrictions and auth methods in return...

santoshbalan

Hi guys,

I went through this challenge, of allowing users to upload the files, but not allowing them to delete the files, which they just uploaded.

The answer is -> put a file by the name of .ftpaccess in the home directory of the ftp login user.

---------------------------
file : .ftpaccess

<Limit RMD XRMD RNFR RNTO DELE>
AllowUser youradminuser
DenyALL
</Limit>
---------------------------

This will allow only the [youradminuser] to removedirectory, delete,rename etc Other users will not be able to delete/rename from this directory, once uploaded. You can get help on the Limit parameter, which is customisable to your requirements.

- Santosh KB
Pune, India

witeshark

Clearly it's a permissions issue. You will find it!