[Bug 69891] New: Possibly unexpected/undocumented behavior when mixing Location and Directory access controls with LIMIT constraints

https://bz.apache.org/bugzilla/show_bug.cgi?id=69891

            Bug ID: 69891
           Summary: Possibly unexpected/undocumented behavior when mixing
                    Location and Directory access controls with LIMIT
                    constraints
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Documentation
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

First of all, the issue https://bz.apache.org/bugzilla/show_bug.cgi?id=47019
seems to be somewhat related/similar to my case.

This (old) issue has been closed a long time ago for being invalid, so I guess
the following case is also considered to be expected behavior(?) from developer
side.

However, I want to stress the fact, that this behavior is not clearly
documented, so this is a major pitfall in my opinion and should be explicitly
documented.

When using configurations like this:

<Location />
  <Limit CONNECT>
    Require all denied
  </Limit>
</Location>

<Directory /my/docroot>
  Require all denied
</Directory>

Apache will implicitly grant full access to all <Directory> sections for all
non-CONNECT requests, despite only "Require all denied" directives being
present in the config.

In my view, this is a _major_ pitfall and should be clearly documented, since
this could have severe security implications.

One could assume that the above "Location" section is equivalent to an empty
section for non-CONNECT requests, since the "Require all denied" directive is
conditional and does not match GET/POST requests.
Quite the opposite is the case, because the conditional "Require all denied"
statement implictily marks the section as auth granted for non-CONNECT requests
and this will render the Directory restrictions inoperable.

I would therefore ask for an explicit warning in the mod_authz_ docs pointing
this out.

I shot myself in the foot with this behavior and want to spare others the same
fate.

Thanks and all the best,
Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.