Subject: Permission denied. (Filename (accept))

From: "Long, Michael" <[email-masked]>
Date: Wed, 17 Mar 1999 10:42:47 -0500

I get the following "Permission denied. (Filename (accept))" error when
trying to download a file to the pub directory using anonymous.  Why?? 

# ftp sparky
Connected to sparky.karmax.com.
220 sparky.karmax.com FTP server (Version wu-2.4.2-academ (1) Thu Mar 11
14:32:48 EST 1999) ready.
Name (sparky:root): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
230 User ftp logged in.  Access restrictions apply.
ftp> pwd
257 "/" is current directory.
ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 10
lrwxrwxrwx   1 root     other          7 Mar 15 16:44 bin -> usr/bin
dr-xr-xr-x   2 root     ftp          512 Mar 15 16:44 dev
dr-xr-xr-x   2 root     ftp          512 Mar 15 16:44 etc
drwxrwxrwx   2 ftp      ftp          512 Mar 15 16:44 pub
drwxr-xr-x   5 root     ftp          512 Mar 15 16:44 usr
226 Transfer complete.
remote: -l
316 bytes received in 0.16 seconds (2 Kbytes/s)
ftp> !ls -l test.mgl
-rwxrwxrwx   1 root     other         15 Mar 17 10:29 test.mgl
ftp> cd pub
250 CWD command successful.
ftp> pwd
257 "/pub" is current directory.
ftp> put test.mgl
200 PORT command successful.
550 test.mgl: Permission denied. (Filename (accept))
ftp> 

My ftpaccess file:

# Server thresholds
#
limit   all   10   Any              /etc/msgs/msg.dead

#
# Access 
#
class           anonftp anonymous *
class           staff   real    *
class           ftp     guest,anonymous *
guestgroup      ftp

#
# Permission capabilities
#
delete          no      anonymous,guest,ftp
overwrite       no      anonymous,guest,ftp
rename          no      anonymous,guest,ftp
chmod           no      anonymous,guest,ftp
umask           no      anonymous,guest,ftp
noretrieve      .notar
path-filter             anonymous,guest,ftp     ^[-A-Za-z0-9\._]*$ ^\. ^-
passwd-check    rfc822  enforce

#
# Mssages and readme's
#
message         /etc/welcome.msg        login
readme          README*                 login
readme          README*                 cwd=*
shutdown        etc/shutmsg
email           [email-masked]

#
# Executables
#
compress        yes             local remote
tar             yes             local remote
ls              yes             local,remote

#
# Event logs
#
log commands real
log transfers anonymous,real inbound,outbound

Many thanks in advance for your help

Michael Long.

 <<Long, Michael.vcf>>

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 17 Mar 1999 11:09:38 -0500 (EST)

On Wed, 17 Mar 1999, Long, Michael wrote:

> I get the following "Permission denied. (Filename (accept))" error
> when trying to download a file to the pub directory using anonymous.  
> Why??

> 550 test.mgl: Permission denied. (Filename (accept))

We usually call this uploading, btw, since we look at things from the
server's point of view.

> path-filter             anonymous,guest,ftp     ^[-A-Za-z0-9\._]*$ ^\. ^-

The filename is being rejected by path-filter.

path-filter's first parameter MUST contain a comma-separated list of one
of the following: anonymous guest real .. you have 'ftp' listed and that
has no meaning here.

On wu-ftpd-vr, you can also use a class=<classname> in this first
parameter.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Harris Kosmidhs <[email-masked]>
Date: Thu, 18 Mar 1999 11:44:34 +0200 (EET)

I just installed wu-ftpd 2.4.2 final with vr16.

I use the old ftpaccess from 2.4.2BETA18.

Previously I could upload files in the /incoming (i had the coorect line
in ftpaccess)
Now I can't. Do I need to change anything in the upload statement?

Thanks
Harris

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 18 Mar 1999 11:21:09 -0500 (EST)

On Thu, 18 Mar 1999, Harris Kosmidhs wrote:

> Previously I could upload files in the /incoming (i had the coorect
> line in ftpaccess) Now I can't. Do I need to change anything in the
> upload statement?

Probably.  In my experience, the upload clauses for many sites didn't work
but the failure wasn't noticed because nobody looked carefully enough and
Unix permissions were protecting the system.  The VR version attempts to
correct these problems in a number of ways.  Most notably for you, upload
is DENIED by default for anonymous users; you MUST have a valid upload
clause to enable it.

I've written a document explaining how to securely allow uploads on your
ftp site.  Read  through
ftp://ftp.vr.net/pub/wu-ftpd/upload.configuration.HOWTO
it should answer your questions.

--

---

From: Harris Kosmidhs <[email-masked]>
Date: Fri, 19 Mar 1999 10:59:22 +0200 (EET)

# specify the upload directory information
upload  /  *             no
upload  /hal/ftp  /incoming     yes     ftp     hal     0660 dirs

isn't it good?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Did they expect us to treat them with any respect %%
%% 			"Final Cut -- Pink Floyd"    %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 19 Mar 1999 12:24:00 -0500 (EST)

> upload  /hal/ftp  /incoming     yes     ftp     hal     0660 dirs

Probably not.

What follows is conjecture based upon my experiences and extensive testing
of the daemon.

-- 

First, remember the _default_ is to ALLOW uploads for all users.  One of
the VR changes (don't know if Bernard has put it in BeroFTPD yet) is to
change the default to deny uploads by default for anonymous users.  Let's
assume your default is to allow uploads.

> upload  /  *             no

Does this do anything?  Probably not.  On most versions of the daemon, the
<rootdir>, '/' here, actually neesd to be the home directory for the user
exaclty as it appears in /etc/passwd (/./ hack and all).  Some of the
later 2.4.2-beta versions are subtly broken and actually _will_ use this
to mean 'anyone who is chrooted' .. meaning anonymous and guest users.  
The only way to know for sure is trial and error testing on your version
of the daemon.

> upload  /hal/ftp  /incoming     yes     ftp     hal     0660 dirs

Does this do anything?  Maybe.  It depends upon whether the earlier rule
worked.  If the earlier rule did NOT work to deny uploads, this rule
probably WILL take effect: uploads were allowed anyway so all it'll do is
set the ownership and permissions.  If the earlier rule DID work, then
this rule probably does not work at all.

Let's say that you tested to make sure the ownership was set as you
expected.  You assumed this meant the upload rules worked.  Don't feel
bad; I labored under the same false sense of security for nearly five
years.

Now we see you allowed directories to be created.  But .. and this is
subtle .. while your second upload clause allowed creation of directories
it would NOT have allowed uploads _into_ those directories.

So, let's say you tested and, sure enough, you COULD upload into the newly
created directories.  This PROVES the first rule did NOT work since it
should have prevented the uploads.

What we have here is a set of rules that appears to work because uploads
were allowed where you expected to be allowed.

But, you say, I tested and I couldn't upload into other areas .. also as I
expected.  Of course not.  But it wasn't the daemon stopping the uploads.
It was the Unix file/directory permissions.

In other words, where you thought you had two rings of security protecting
your system, the outer ring (the FTP daemon's upload clauses) were broken;
all that was protecting your server was the last-ditch permissions check
provided by the underlying OS.

This breakage was VERY subtle.  In fact, I looked at it for the better
part of a year, convinced something wasn't quite Kosher but not quite able
to put my finger on WHY it was broken.  The many head-shaped dents in my
office walls are evidence of my reaction when I finally realized just why
and how badly broken the upload clauses were.

--