httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject FileSystem v.s. Other Resources [was configurable Location?]
Date Wed, 04 Feb 2004 22:54:01 GMT
At 03:39 PM 2/4/2004, wrote:
>But then if I play devil's advocate, someone could see the new directive and turn it on
when it's not appropriate and cause Bad Things to happen.  Mainly I'm looking for comments
on whether this should be configurable or not.

Yes, I'm one who will agree with your devil's position :)  I know the problem
you are trying to solve, and changing the behavior of <Directory > isn't quite
the solution...

Issue 1:

Walking the filesystem (the stat aspect of Directory and File) for something
that doesn't live there is stupid :)  We agree, and this must be fixed in 2.1

Issue 2:

Matching directories when something is outside of the filesystem is simply
wasteful, and here too we agree.

The problem is that you want to add layers of additional directives, which
would change the behavior of <Directory > or <Location >, in ways that would
allow the user to seriously compromise what they had explicitly configured
for security.  This is unwise.  Let's look at the two issues above;

Effect/Issue 1:

Bypassing the filesystem canonicalization would be very bad on certain 
platforms such as windows, depending on case sensitivity, etc.  It would
also bypass *user configured* options such as avoiding symlinks.

Effect/Issue 2:

Bypassing the directory block walk would ignore the very <Directory >
sections that the user explicitly put in their config.  This too is bad.

There is only one way to avoid these consequences, and still save ourselves
the pain of the filesystem walk and <Directory > block handling...

=== Break out file handling as a separate component ===

I've proposed in the past the simple directive

FilesystemMount /path/to/files

Consider the existing directive, DocumentRoot, as shorthand for;

<Location />
FilesystemMount /old/root/

Also consider the Alias /foo /path/to/bar directive as shorthand for;

<Location /foo>
FilesystemMount /path/to/bar

But wait, there is more :)  We have a default handler.  Simply modify it to
be the default_file_handler.  Insert it ONLY if the appropriate FilesystemMount
directive exists in the particular location block.

What happens to requests that don't have a FilesystemMount block,
and don't have another handler (e.g. SetHandler info-handler or whatever)?
These requests would error out with a 500 - there is no way for the server
to handle them.

What happens to our old default handler (inserted at all times?)  It becomes
a simple error-500 handler if nothing else intercepts the request.

Note that the exact semantics could change (my naming isn't all that great
either) - but the key detail is that mount directives within a given <Location >
are much safer and easier to follow than arbitrary Mount src dst directives
which may be order and/or length dependent, creating confusion for the user.

So in short, veto on the original proposal to give users gun to point at foot.
+1 on the concepts that we quit interrogating the filesystem when the user
wants to serve non-files, and quit walking directory blocks for things that
do not live in directories.  Let's do this in 2.1 by splitting out the file system,
and if the filesystem module isn't handling a request, it won't be serving
content but also won't be invoking the directory walk or stat-ing files.

Oh last observation - it should become (in 2.1) nearly impossible for folks
to just bork around with the contents of r->filename and r->finfo, first by 
stripping them from the request rec, and second by providing an API to
the filesystem module that lets another module link into another file.
That API would prevent module authors from bypassing the filesystem
module's internal security.  If they want different behavior, they can plug
in their own backend handler to deal with the whole request process.


View raw message