William A. Rowe, Jr. wrote:
At 03:39 PM 2/4/2004, [EMAIL PROTECTED] 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,
great!
and changing the behavior of <Directory > isn't quite the solution...
I'm only changing <Location > ... <Directory > is unaffected.
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
cool!
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 >,
only <Location >, in a way that IMO is consistent with the existing documentation, but not the existing code of course.
>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.
only for <Location > If the admin is telling us the content is outside the filesystem, I don't think filesystem canonicalization or symlinks are relevant.
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.
This is only for <Location > . There is no change to the behavior of <Directory >.
There is only one way
that sounds kinda religious...in software there are generally a number of ways to solve a problem :-)
to avoid these consequences, and still save ourselves the pain of the filesystem walk and <Directory > block handling...
I'm only changing <Location >
=== Break out file handling as a separate component ===
I've proposed in the past the simple directive
FilesystemMount /path/to/files
At first glance it looks like a key difference is that you are approaching it by saying that it's OK to have <Location > map to a real filesystem and providing config to explicitly specify the mapping. I'm advocating going the other way and allowing <Location > to be treated as if it is really outside of the filesystem.
A complication to treating <Location > as if it's outside the filesystem is the doc that states <Location /> is a quick way to apply a config to the whole server. It will indeed do that today, unfortunately. I believe another quick way to get the same result is to put your config directives outside of any container. If that's true, I would prefer to see that doc for <Location /> removed. If the change to the behavior of <Location > is configurable, this is not an issue. If it's not configurable, then we probably should treat <Location /> as if it's in the filesystem - a special case for backwards compatibility.
I'd like to study your comments more after my coffee kicks in :-) Obviously you've given a lot of thought to this issue so I want to see if I can understand where you're coming from.
Greg
