Re: guest-root and upload
Dave Mackintosh <[email protected]> Sat, 03 Apr 2004 10:30:12 -0500
| Newsgroups | gmane.network.ftp.wuftpd.user |
|---|---|
| Message-ID | <1081006212.20620.76.camel@saturn> |
On the off chance anyone cares: I abandoned the guest-root usage, and resorted to using the filesystem permissions to enforce the ownership scheme I wanted. We will trust filesystem permissions to keep users separated. In /opt/UXdmz/private, all customer directories receive a chmod g+ws, setting the set-GID bit on the directory. I then added a defumask 660 guests directive to the ftpaccess file. This exhibits the behaviour I wanted: uploaded files get the uploader as an owner, and the ftp-admin's group as the group, with permissions suitable for deletion by the ftp-admin through ftp. Interestingly this all works perfectly regardless of the 'upload' directives -- I'm currently running with a upload /opt/UXdmz/ftproot * no directive as the only upload directive in the ftpaccess file, which according to the documentation implies no one should be able to upload anything anywhere. I can only conclude that the upload directives are being completely ignored. This behavior is consistant on both Solaris and Linux builds of 2.6.2 (with the two current patches). On Sun, 2004-02-08 at 10:35, Dave Mackintosh wrote: > Greetings, list > > I've gone through the old archives of this list (I notice that the archives only > go up to April 2003, is that intentional?) and can't find a solution to my problem -- > although I see the symptoms described a couple of times. > > So: > > wu-ftpd 2.6.2 (with the two current patches) > Solaris 8 > > My problem is that when I use the guest-root directive, user accounts end up in > the chroot directory, not their local-home directory. When I _don't_ use the > guest-root directive, the file mode and ownership parts of the upload directive > are ignored. > > The main goal is to get the file modes and ownerships correct, I really don't care > about guest-root because the /./ hack works properly for me. > > OK, server layout. > > The ftp server is rooted at /opt/UXdmz/ftproot. All users get > chrooted to this directory, and it has a complete (and functional) > set of /lib and /usr content. > > So a sample user might look like this in /etc/passwd: > > dave:x:516:511:FTP Client:/opt/UXdmz/ftproot/./private/dave:/bin/false > > And in /etc/group, the relevant lines are: > > guest:*:400:dave > dave::511: > > Note that there are other user accounts as members of the 'guest' group, but > they have been removed from this example. > > A couple of directories which might be relevant: > > dr-x--x--- 20 admin guest 512 Jan 22 10:35 /opt/UXdmz/ftproot/private > dr-xr-xr-x 2 root other 512 Feb 6 11:52 /opt/UXdmz/ftproot/etc > drwxrwx--- 2 dave admin 512 Feb 6 11:53 /opt/UXdmz/ftproot/private/dave > > User dave also has an entry in /opt/UXdmz/ftproot/etc/passwd" > > dave::516:511::/private/dave: > > We are using file-system level permissions to prevent users from > seeing the presence of each other on the system. With this layout, > user dave can cd into and through /private, but can't list the > content. So he can't see other users, and because he isn't a member > of the admin group, he can't cd into other users accounts even if he > knows they are there. It also means that an admin account has full > read-write permissions to all user directories, to either drop off > files for users or clean up after them. (We know this isn't perfect, > but it works OK enough for our requirements.) > > This permissions layout works as intended both with and without the > guest-root directive. > > So when dave connects to this ftp server and uploads a file, I'd like > it to obey this upload directive: > > # this upload parameter controls the /private areas > upload /opt/UXdmz/ftproot /private/* yes * admin 0664 > > IF I am _not_ using guest-root, I get file permissions like this: > > -rw-r--r-- 1 dave dave 1040 Feb 8 10:24 /opt/UXdmz/ftproot/./private/dave/test.gz > > IF I _am_ using guest-root, I get file permissions like this: > > -rw-rw-r-- 1 dave admin 1040 Feb 8 10:24 /opt/UXdmz/ftproot/./private/dave/test.gz > > ...which is what I want -- BUT when dave logs in he gets dumped in > /opt/UXdmz/ftproot and must manually cd private/dave before > performing his upload. > > The documentation makes a big deal about the post-chroot /etc/passwd > being 'locally correct', and as far as I can tell it is. But I'm obviously > missing something and can't see what it is. > > If anyone has any ideas (or would like more information) please let me know. > > Thanks! > > Here's my /etc/ftpaccess file: > > # For more information see the O'Reilly book "Managing Internet > # Information Services". Chapter 5. > # > # Modification History > # 9 March 1999 [ Chris Kramer ] > # Created > # 1 October 2001 [ David Mackintosh ] > # Modified for use on relay > > # > # real logins do not get chroot'd so limit those directly > # > #class local real *.myco-name-replaced.com > class guests guest * > class anon anonymous * > > # > # this disables anonymous access > defaultserver private > > # Greeting -- be terse > greeting terse > > # > # Stop after 40 concurrent connections! This is a SPARC 1+ ! > # > limit guests 40 Any /msgs/ftpbusy.msg > limit anon 40 Any /msgs/ftpbusy.msg > > # Default umask > #defumask 113 > > # > # Limits to 1 failed logins. Slows door knockers. > # > loginfails 1 > > # > # UNIX group of all customer FTP logins. > # > guestgroup guest > guestuser * > email [email protected] > message /msgs/welcome.msg login > message .message cwd=* > readme README* login > readme README* cwd=* > > # lock everyone into the chroot base: > #guest-root /opt/UXdmz/ftproot > > # ...and lock each user into their home directory: > #restricted-uid * > > # > # log all command and transfers > # > log commands real,guest,anonymous > log transfers real,guest,anonymous inbound,outbound > log syslog+xferlog > > # > # directory aliases > # > alias inc /incoming > alias priv /private > > # > # define cdpath > # > cdpath /incoming > cdpath /pub > cdpath / > > # > # allow compression and tarification > # > compress yes local > compress yes guests > compress no anon > tar yes local > tar yes guests > tar no anon > > # > # where to look for a shutdown message > # > shutdown /tmp/shutdown.msg > > # > # these all default to "yes" for everybody... > # > chmod no anonymous,guest # no anon/guest chmods > delete no anonymous # no anon/guest deletes > overwrite no anonymous,guest # no anon/guest overwrites > rename no anonymous # no anon/guest renames > umask no anonymous,guest # no anon/guest umasks > > # > # encourage anon users to supply a real email address as password > # > passwd-check rfc822 warn > > # > # prohibit anon/guest uploads to oddly named files > # > pathfilter anonymous /msgs/ftpbadpath.msg ^[-A-Za-z0-9\._]*$ ^\. ^- > pathfilter guest /msgs/ftpbadpath.msg ^[-A-Za-z0-9\._]*$ ^\. ^- > > # don't permit retrieval of our dot files > noretrieve .notar > noretrieve /etc/passwd > > # > # allow uploads into the ~/incoming directory only -- but no subdirectories > # > upload /opt/UXdmz/ftproot /incoming yes admin admin 0664 nodirs > > # > # this upload parameter controls the /private areas > # we rely mostly on filesystem permissions to keep users out of each other's > # private areas > # > upload /opt/UXdmz/ftproot /private/* yes * admin 0664 > # > # this upload parameter controls /pub > # > upload /opt/UXdmz/ftproot /pub/ yes admin admin 0644 -- /\oo/\ / /()\ \ David Mackintosh |