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 |