Subject: AFS & anon ftp/incoming

From: Michael Helm <[email-masked]>
Date: Wed, 29 Oct 1997 09:35:23 -0800 (PST)

/afs & anonymous ftp /incoming (uploads) have problems working
together.  I've found a work-around but want to find something
that could be included in the wu-ftpd distribution.

We want to run anonymous ftp with an "/incoming" directory for
uploads.   We are running solaris 2.5.1 & wu-2.4.2-academ[BETA-15].
We are also running afs (3.4a2).  What we want to do is take 
advantage of the security & file management that afs offers
(don't laff -- it does have some advantages).  We also want to
extend the least number of privileges possible to the ftp server
itself -- that includes, for afs aficionados, not granting any
afs tokens to the ftpd daemons if possible.  

This works fine for classic read-only ftp but it's a problem for
any upload directories.  We found we could finagle privileges
around so uploads should work securely for a separate afs volume --
that is, an unprivileged user could write in /incoming --
but ftpd uploads would fail because of a "fchown" call.

Suppose you have this in ftpaccess:

upload /afs/cell.dom.ain/ftproot /incoming   yes     ftp ftp 0600 nodirs

Users who attempt to upload get the error (paraphrasing)
fchown not owner

This is a classic afs error.

In wu-ftpd's ftpd.c (around line 2072) ftpd regains root, does fchown,
then gives up root again.  This isn't enuf in afs -- it needs
an afs privilege.  A limitation of afs is that to do chown,
your afs token must have a very strong admin privilege;
no ftpd is going to be allowed to have that.

For anonymous ftp uploads, tho, I don't care about ownership,
& it's ok that these files inherit the afs nobody uid & the
default directory gid, since disposition of the files is taken
care of by out of band communication.   So I commented out this
fchown operation in ftpd.c (about line 2072):

        delay_signaling(); /* we can't allow any signals while euid==0: kinch */
        (void) seteuid((uid_t) 0);
        if ((fchown(fdout, uid, gid)) < 0) {
            (void) seteuid(oldid);
            enable_signaling(); /* we can allow signals once again: kinch */
            perror_reply(550, "fchown");
            return;
        }
        (void) seteuid(oldid); 
        enable_signaling(); /* we can allow signals once again: kinch */

This change gets me what I want: files are (uid,gid)=(afs nobody, default),
the users can upload without errors, & the fchown step is skipped.

What I want is a general solution that would get in the distribution
so I wouldn't have to go back & tweak this every time the software
changes.

Maybe what could be done is to wrap fchown in another function that
would test for /afs usage & not bail out when fchown failed on
an afs file system.   Testing for whether your working directory
is in afs is hard, & maybe my usage conditions aren't general enuf.
fchown only seems to be called once & only in ftpd.c.

---

From: Rainer Schoepf <[email-masked]>
Date: Wed, 29 Oct 1997 18:52:26 +0100 (MET)

> Users who attempt to upload get the error (paraphrasing)

I got around it by writing

upload /afs/cell.dom.ain/ftproot /incoming   yes nodirs

If you do this, wu-ftpd doesn't do the fchown. This is OK, as file
ownership and group/world permission bits are essentially irrelevant
in AFS.

-- 
   Rainer Schöpf
   Zentrum für Datenverarbeitung           A point of view can be a dangerous
    der Universität Mainz                  luxury when substituted for insight
   Anselm-Franz-von-Bentzel-Weg 12         and understanding.
   D-55099 Mainz
   Germany                                  Herbert Marshall McLuhan:
   <[email-masked]>                          The Gutenberg Galaxy

---

From: Mitch Collinsworth <[email-masked]>
Date: Wed, 29 Oct 1997 15:40:42 -0500

I have a different problem entirely.  Essentially a denial of
service attack.

My experimentation showed that the minimum afs permissions needed
on the incoming directory are "system:anyuser li" (when running
with unauthenticated ftpd).  I wanted just "i", but with out "l"
uploading wouldn't work.  I then have "system"authuser rld" so that
our users can pick up the uploaded files and delete them. That
seemed ok at the time and it worked fine for a period of years.

Recently however, the warez crowd has begun uploading all manner
of junk to the incoming directory.  It doesn't seem to matter that
they can't get any of it back from the server.  It's not obvious
to me that they have even figured that out.  Each time I've
re-enabled the directory more junk has appeared  (Has anyone
actually ever succeeded in locating a functional neuron in a warez
user's head?)  I tried reporting several of them to their admins,
hoping that at least a few would get a lecture or an account
yanked (or worse) and might perhaps put the word out on the street
not to mess with us, but that doesn't seem to have helped.  I've
had to shut off the incoming directory altogether, and now when
someone needs to use it they'll have to ask me to enable it.  Does
anyone know how to initiate communication with a distributed
intelligence vaccuum?

-Mitch

-- 
                     "Families can't trust Disney"

---

From: "Tianyu Li D'Amore" <[email-masked]>
Date: Wed, 29 Oct 1997 13:30:38 -0800

You can also mount a regular UFS on top of afs so /afs/whatever/ftp/incoming
would be a regular UFS partition configured to accept ftp uploads.

Tina

---

From: "Tianyu Li D'Amore" <[email-masked]>
Date: Wed, 29 Oct 1997 13:51:34 -0800

Just want to point out that although AFS ignore UNIX directory permissions 
and use it's ACL instead, it does honor the File permission/ownership and
there's no ACL for files in AFS.

Tina

---

From: Michael Helm <[email-masked]>
Date: Wed, 29 Oct 1997 16:02:10 -0800

Mitch Collinsworth writes:
> not to mess with us, but that doesn't seem to have helped.  

It seems to have helped for us; but perhaps it's only a momentary
pause.  I complained about every access to the upload directory that
wasn't related to our business; this wouldn't be practical for
everyone.

---

From: "James T. Roberts - MD6 ~" <[email-masked]>
Date: Wed, 29 Oct 1997 16:29:56 -0800 (PST)

> there's no ACL for files in AFS.

AFS treats the owner r/w bits as public r/w bits and ignores the rest.  

In other words, a UNIX "chmod u+w" effectively becomes a "chmod a+w" on an AFS
file, assuming system:anyuser write.  Refer to page 2-4.15 of the TransArc
User Training Course Notes.

========================================================================
James Taylor Roberts 
[email-masked]

 CARPE JESUS                 |      Fight chicken abortion!
SEIZE THE WAY                |           Boycott eggs!

The opinions expressed herein are not necessarily Intel's.  Actually if
they had any opinions whatsoever on egg-eating, I'd be surprised....
========================================================================