httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@leland.Stanford.EDU>
Subject Re: FindFirstFile
Date Sun, 05 Jul 1998 04:44:44 GMT
On Sat, 4 Jul 1998, Ben Laurie wrote:

> > This has the added benefit of not screwing up dots and slashes in
> > PATH_INFO, as the current os_canonical_filename() does.
> No it doesn't! That's what I spent all that energy on fixing!

Well, trailing dots in PATH_INFO are currently removed. That code should
probably be moved into sub_canonical_filename().

> However, I'm beginning to agree with you. Actually, I seem to remember I
> started out agreeing but went astray somewhere down the line. 

There are two issues as far as I can tell:

1. There are some filenames that Windows treats as the same, e.g.,
trailing dots and spaces, and case stuff. These we *can* silently rewrite
(though see point 2). Then there are characters (< > " : / \) and
other thingies (aux, con, etc...) that are "reserved" by the OS, and we
shouldn't try to read from. There is no legal way for a filename to
contain a colon, for example, so we should reject requests that contain
them. This would prevent the ::$DATA problem, for example (although we
don't appear to be vulnerable to to right now).

2. On Unix there's a tighter associativity between URLs and filenames,
since a filename can be described uniquely. i.e., consider the following:

DocumentRoot /foo
Redirect /old /new

On Unix, there is no way to access the /foo/old directive, even though it
is in the document root. On Win32, I can access /old%20, /old., or even
/OLD and get to the directory I presumably was trying to remove access to.

Of course, the proper thing to do is to realize that anything within a
public document space is subject to access, and either remove /foo/old, or

<Directory /foo/old>
order allow,deny
deny from all


> But I think that throwing stuff out for non-matching case is probably
> going too far.

I agree, since the "canonical" name as far as the Windows *user* is
concerned (i.e., what appears in Windows Explorer) could be lower or upper
case, regardless of what Apache thinks. Of course, this throws off my
argument for not silently canonicalizing names as per point 2 above, since
any URL manipulation you could get around with dots or spaces, you could
also get around by changing case.


I dunno.

-- Alexei Kosut <> <>
   Stanford University, Class of 2001 * Apache <> *

View raw message