Subject: Wildcard/globbing in ftpaccess file

From: Aaron Holtz <[email-masked]>
Date: Tue, 7 Oct 1997 22:17:13 -0400 (EDT)

This talk of 'noretrieve' in the ftpaccess file has me wondering:
Would it be difficult to implement wildcards in the ftpaccess file?
For example:

noretrieve /etc/*
noretrieve /bin/*

That way no file in that directory could be retrieved?  I've tried some
combinations in the ftpaccess file, but I can simply 'cd' to /etc/ and
grab the file that I want that isn't explicitly denied.  I'm working on
fixing this by setting up a chroot'd guest account filesystem, but since
there are 30,000+ accounts on this server, a quick fix would be nice as
well.  I'm explicitly denying files right now, but was wondering if there
is a better approach using the existing code.  A man page I read
stated no globbing is done, but someone out there may have hacked a 
local version for themselves that does this.  Thanks!

							--Aaron

--------------------------------------------------------------------------
Aaron Holtz
First Network Group    "The First Name in Internetworking"
Manager, UNIX Systems Admin
Email:  [email-masked]
"Those that do not accept Unix are doomed to reproduce it"
--------------------------------------------------------------------------

---

From: Aaron Holtz <[email-masked]>
Date: Wed, 8 Oct 1997 00:04:51 -0400 (EDT)

In an update to my previous question, I was told that what should be the
case is that if I use:

noretrieve /etc/

then that would prohibit any file from being gotten out of the /etc
directory.  This is true if I try and grab the file by doing:

> get /etc/file

However, if I:

> cd /etc
> get file

I can retrieve the file!!!   This looks to be a bug in the intended coding
for the noretrieve option.  It was suggested to me to report this bug to
Stan, which I (as soon as I find the proper address!) will do.  Just an
FYI and an update to the list.  If anyone has the proper
method/channel/email address for bug reporting, I'd greatly appreciate it.

								--Aaron

---

From: Michael Douglass <[email-masked]>
Date: Tue, 7 Oct 1997 23:27:37 -0500

On Wed, Oct 08, 1997 at 12:04:51AM -0400, Aaron Holtz said:

This is almost exactly the type of option that I was asking about
a while back...  Well, almost exactly--but not quite.  If this
feature is programmed into wu-ftpd, then programming a 'retrieve
yada/yada/yada' should be simplistic.  Basically, what I'd like to
be able to do is specify:

noretrieve *
retrieve ~/

(~ behind a symbol for the home dir)

The reason I say this should be easy is because you must be checking
the files being retrieved against the list of 'noretrieve' before sending
the file.  And, this is the same thing--except instead of specifying those
files that can't be retrieved, I'd like to specify directories that can be
retrieved from.  (And if that is possible, then being able to use wild
cards for the current user's home directory would be simplistic...)

Thoughts.. Just thoughts...

-- 
Michael Douglass
Texas Networking, Inc.

  "For all that you see, there is much hidden from your view;
   for all that you know, there is truth yet to be learned."
    - Me, some years ago.

---

From: [email-masked]
Date: 8 Oct 1997 18:44:47 GMT

Pink elephants with an attitude inspired Aaron Holtz <[email-masked]> to tell garfield.mail.wu-ftpd:
: noretrieve /etc/

: then that would prohibit any file from being gotten out of the /etc
: directory.  This is true if I try and grab the file by doing:

: > get /etc/file

: > cd /etc
: > get file

: I can retrieve the file!!!   This looks to be a bug in the intended coding

I use noretrieve passwd group core
which blocks downloads of the files I don't want downloaded.. from any
directory.. globbing would be easier, but as far as I can tell from the
above example it makes sense.. there's no /etc/ in the filespec.
If the code was changed to reflect the full path you may run into problems
with symlinked directories where the 'real' path is not the link but you
might be using the link in ftpaccess.

: for the noretrieve option.  It was suggested to me to report this bug to
: Stan, which I (as soon as I find the proper address!) will do.  Just an
: FYI and an update to the list.  If anyone has the proper
: method/channel/email address for bug reporting, I'd greatly appreciate it.
[email-masked] though [email-masked] is the regular bugs address
(I mean.. it's in the top-level README file.. not that hard too find is it?
:)

-- 
Perry Rovers ([email-masked])