Return-Path: Delivered-To: apache-bugdb-archive@hyperreal.org Received: (qmail 16424 invoked by uid 6000); 21 May 1998 00:50:05 -0000 Received: (qmail 16363 invoked by uid 2001); 21 May 1998 00:50:00 -0000 Date: 21 May 1998 00:50:00 -0000 Message-ID: <19980521005000.16362.qmail@hyperreal.org> To: apache-bugdb@apache.org Cc: apache-bugdb@apache.org, From: Brian Behlendorf Subject: Re: general/2030: spelling error possibilities include files that shouldn't be seen Reply-To: Brian Behlendorf Sender: apache-bugdb-owner@apache.org Precedence: bulk The following reply was made to PR general/2030; it has been noted by GNATS. From: Brian Behlendorf To: "Daniel C. Stevenson" 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