You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Brian Behlendorf <br...@hyperreal.org> on 1998/05/21 02:50:00 UTC

Re: general/2030: spelling error possibilities include files that shouldn't be seen

The following reply was made to PR general/2030; it has been noted by GNATS.

From: Brian Behlendorf <br...@hyperreal.org>
To: "Daniel C. Stevenson" <da...@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
 >done.
 
 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.
 
 	Brian
 
 
 --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
 pure chewing satisfaction                                  brian@apache.org
                                                         brian@hyperreal.org