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, 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/ </Location> Also consider the Alias /foo /path/to/bar directive as shorthand for; <Location /foo> FilesystemMount /path/to/bar </Location> 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. Bill
