upload

Created by dave. Last edited by dave, 18 years and 193 days ago. Viewed 3,571 times. #4

[diff] [history] [edit] [rdf]

labels

attachments

Struggling with Wu-Ftpd's Upload Clause

I'm using wu-ftp-2.6.2-8 (hacked slightly to make it build on FC2).

Here's the scenario. I have multiple incoming users who I want to keep as separate from each other as possible. Like, to the point that I don't want them to even know each other exists.

At the same time, I need a regular user-level account to be able to act as an ftp administrator account, able to create and delete files in each end-user's directory.

OK, so we have a user testuser who belongs to the group testuser. And we have a user admin who belongs to the group admin.

At the filesystem level, the permissions on /home/testuser are testuser:admin 770.

On the ftp server, we use the guestuser clause. As in:

# Chroot all users to their home directory by default
guestuser *
# If you wish to allow user1 and user2 to access other
# directories, use the line below:
realuser admin

So now the user admin has the run of the entire FTP server, but since he's staff we don't have much to fear from him.

Right, the tricky part comes in the upload directives. Here's how we control the end user's uploads:

upload /home/testuser * yes testuser admin 0664 dirs

This works as advertised. testuser is chroot'd to /home/testuser, and has this upload applied to everything under it (the '*'). So testuser can do this:

$ ncftp -u testuser -p notthispassword localhost
NcFTP 3.1.8 (Jul 27, 2004) by Mike Gleason (http://www.NcFTP.com/contact/).
Connecting to localhost…                                                                                                         pioneer.fictional.net FTP server (Version wu-2.6.2-8) ready.
Logging in…              
User testuser logged in.  Access restrictions apply.
Logged in to localhost.                                                                                                                ncftp 
/ > mput curling
curling:                                                51.00 B    1.24 kB/s  
ncftp / > mkdir x
ncftp / > cd x
ncftp /x > mput curling
curling:                                                51.00 B    1.25 kB/s  
ncftp /x > mkdir x
ncftp /x > cd x
ncftp /x/x > mput curling
curling:                                                51.00 B    1.27 kB/s  
ncftp /x/x > quit

And if we double check:

$ ls -l /home/testuser/x/x
total 4
-rw-rw-r--  1 testuser admin 51 Nov 30 16:01 curling

So that works as advertised; great. The admin user doesn't quite work the same way.

The admin user's relevant upload clause is:

upload /home/admin /home/testuser yes testuser admin 0664 dirs

As in, for the user with the defined home directory "/home/admin", in the directory "/home/testuser", apply these ownerships and permissions.

Which kind of works:

$ ncftp -u admin localhost NcFTP 3.1.8 (Jul 27, 2004) by Mike Gleason (

http://www.NcFTP.com/contact/). Connecting to localhost… pioneer.fictional.net FTP server (Version wu-2.6.2-8) ready. Logging in… Password requested by localhost for user "admin".

Password required for admin.

Password: ********

User admin logged in. Logged in to localhost. ncftp /home/admin > cd ../testuser ncftp /home/testuser > mput curling.rox curling.rox: 51.00 B 1.26 kB/s ncftp /home/testuser > mkdir y ncftp /home/testuser > cd y ncftp /home/testuser/y > mput curling.rox curling.rox: 51.00 B 1.27 kB/s ncftp /home/testuser/y > quit

...and then we double-check:

$ ls -l /home/testuser/ /home/testuser/y /home/testuser/: total 16 -rw-rw-r-- 1 testuser admin 51 Nov 30 16:08 curling -rw-rw-r-- 1 testuser admin 51 Nov 30 16:09 curling.rox drwxrwxr-x 3 testuser admin 4096 Nov 30 16:01 x drwxrwxr-x 2 testuser admin 4096 Nov 30 16:09 y

/home/testuser/y: total 4 -rw-r--r-- 1 admin admin 51 Nov 30 16:09 curling.rox

...in other words, at the /home/testuser level, everything works as expected. However, this does not carry through subdirectories, as admin now creates files that testuser cannot delete.

(Perhaps) perversely, one can do this:

upload /home/admin /home/testuser yes testuser admin 0664 dirs
upload /home/admin /home/testuser/* yes testuser admin 0664 dirs

...which will fix the problem for /home/testuser/y. It will, however, not help you one bit when you create /home/testuser/y/y.

So. Why does the upload directive work for end users who are guest-rooted, while not working for real users who have greater-than-average write permissions?

What am I doing wrong?

Later: It has been pointed out to me that the flaws in this configuration are:

testuser cannot delete or overwrite files that admin has created
testuser cannot write into or delete directories that admin has created
on solaris, you need /usr and /bin present and populated to make directory listings work

Overall, these are not lethal flaws, in that it places a higher burden on the admin user to keep things cleaned up, but everything else pretty well works.

Personally though, my view is that users (and admins) should not be creating directory trees but uploading .zip and .tgz files instead.

no comments | post comment

see also:
wu-ftp	snipsnap-index	Meta-Index	Password Managers
dave	build on FC2	snipsnap-search	cyrus
start	Netscreen	Juniper	DHCP server
ypserv doesn't g...	cyrus

upload

Struggling with Wu-Ftpd's Upload Clause

Virtual Dave Megaplex:

Useful: