Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232980 - .htaccess permissions do not always cascade correctly
Summary: .htaccess permissions do not always cascade correctly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: httpd
Version: 3.8
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-19 18:50 UTC by Travis Saling
Modified: 2008-04-09 18:29 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-22 12:26:48 UTC


Attachments (Terms of Use)

Description Travis Saling 2007-03-19 18:50:14 UTC
Description of problem:

Restrictions from a <Files> directive in an .htaccess file can override a
subdirectory's global .htaccess permission settings.

If, for example, we have the following .htaccess file in /foo:

<Files myfile*>
        AuthType Basic
        AuthName "This is directory /foo"
        require user jim jane
</Files>

Now, in a subdirectory /foo/bar, if we have the following .htaccess file:

AuthType Basic
AuthName "Now you are accessing /foo/bar"
require valid-user

It seems to me that every file /foo/bar/* should be accessible to anyone with an
account. But in practice, if a file exists with a name like
/foo/bar/myfile1.pdf, it will only be accessible to users "jim" and "jane" - so
the file /foo/.htaccess is taking precedence, incorrectly. This is also
demonstrated since the prompt shown in the authentication dialog box will be
"This is directory /foo" rather than "Now you are accessing /foo/bar" for those
files that match the directive in /foo/.htaccess.

Version-Release number of selected component (if applicable): Apache 2.0.46


How reproducible: Always


Steps to Reproduce:
1. Create .htaccess file, as shown above, in a directory "/foo"
2. Create another .htaccess file, as shown above, in the directory "/foo/bar"
3. Create a file myfile1.txt (or whatever) in /foo/bar
3. Try to access the file created in step 3 from an account other than the one's
specified in /foo/.htaccess
  
Actual results: /foo/.htaccess takes precedence over /foo/bar/.htaccess


Expected results: /foo/bar/.htaccess should take precedence, since it is closer
(in the same directory) to the files in question.


Additional info:

Comment 1 Joe Orton 2007-03-22 12:14:30 UTC
Directives within the <Files> section are applied later than those in the
.htaccess file, so this is generally expected behaviour.

http://httpd.apache.org/docs/2.0/sections.html#mergin

You may able to obtain the desired behaviour by adding a "Satisfy any" into the
<Files> section.

Comment 2 Joe Orton 2007-03-22 12:26:48 UTC
Sorry, no, Satisfy doesn't help here.

I can't see any simple way to achieve what you want here: if you only want the
file* match to apply within /foo (and not recursively) it could be moved to
httpd.conf and turned into a LocationMatch, for example.

But the configuration is being applied as expected per the above link.  Please
contact support if you require further assistance with the configuration issue.


Note You need to log in before you can comment on or make changes to this bug.