httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: FileSystem v.s. Other Resources [was configurable Location?]
Date Thu, 05 Feb 2004 15:22:35 GMT
Thanks for the feedback, Will.

William A. Rowe, Jr. wrote:
> 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...

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


> 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 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.


View raw message