www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@hyperreal.org>
Subject Re: general/2030: spelling error possibilities include files that shouldn't be seen
Date Thu, 21 May 1998 00:50:00 GMT
The following reply was made to PR general/2030; it has been noted by GNATS.

From: Brian Behlendorf <brian@hyperreal.org>
To: "Daniel C. Stevenson" <daniels@media.mit.edu>
Cc: apbugs@Apache.Org
Subject: Re: general/2030: spelling error possibilities include files
  that shouldn't be seen
Date: Wed, 20 May 1998 17:45:33 -0700

 At 07:20 PM 5/20/98 -0400, Daniel C. Stevenson wrote:
 >>mod_autoindex does this as well - it will list the contents
 >>of a directory regardless of what the actual permissions on
 >>each file are.  This is the "expected" behavior for something
 >It's not even the case of permissions on the file system level, but also
 >permissions set by Apache. I have various configuration rules that deny
 >requests for certain files. While moving them to another directory would be
 >good, that doesn't solve the possible problem of the user finding the names
 >of hidden directories. Or, in the case of a scripts directory, listing the
 >name of every CGI script.
 Sure.  Again, that's the semantics of the autoindexer as well, so I don't
 think we're being inconsistant.  
 To really determine if a given file "should be shown", you essentially have
 to go through all the request machinery for each file, since a config
 parameter in an htaccess file way at the document root could affect its
 availability.  It could get kinda ugly.... but if you want to submit a
 patch to do this optionally by some config parameter, we'd consider adding
 it.  You could also *possibly* detect if mod_autoindex is compiled in and
 if so follow the IndexIgnore setting, but that could be complicated and
 require exporting of symbols to work correctly with dynamic linking.
 >In the end, I think the security concerns could be addressed by adding a
 >3-state flag for the module. If the flag is 0, only when a single match is
 >discovered is it returned; a 404 is returned otherwise. If the flag is 1,
 >only a list of multiple matches are returned (not very usual, but good for
 >completeness). If the flag is 2, single and multiple matches are returned,
 >depending on what is appropriate.
 Hmm, interesting - again, do up a patch and we'd consider it.
 >I recognize that the problem is not terribly serious or risky, and I don't
 >mean to burden your time. I have been using and enjoying Apache since
 >0.8.x, and I am very grateful for the excellent work the Apache Group has
 No problem, it's just at this point our coding resources have to be applied
 to bug fixing and being "consistant" everywhere we can, so that's the lens
 I was looking at your report with.
 pure chewing satisfaction                                  brian@apache.org

View raw message