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