Am Samstag, 28. September 2013, 09:19:28 schrieb Eric Covener:
> I've come back to this because I've struggled in another area with
> access_checker vs. access_checker_ex. I really think we need basic
> access control outside of Require and Satisfy.
>
> I have a copy of the "Forbidden" directive in mod_authz_core and I
> am currrently allowing ON/OFF flags.
>
> * using a new directive means someone won't casually add "forbidden
> OFF" when they think they're turnong on more access control with
> Require
> * we can document that "forbidden OFF" is extreme from the start.
>
> I am on the fence about having an argument at all. My fear is that
> it will evolve into a misguided FAQ of 'try forbidden OFF if you
> get a 403' then we're right back to
>
> <Files .ht*>
> Forbidden
> </Files>
>
> ...
>
> <Location />
> ...
> Require ldap-group cn=foo
> Forbidden OFF
> </location>
>
> Any thoughts on keeping the flag?
I am not sure this is enough. I think it can happen that one wants to
override one specific Forbidden but not any others. Consider the
following config:
<Directory />
Forbidden
</Directory>
<Directory /srv/www>
Forbidden off
</Directory>
<Files .ht*>
Forbidden
</Files>
<If ! %{HTTP_METHOD} -in { "GET", "POST", "HEAD" } >
Forbidden
</If>
If I now want to allow PUT/DELETE for a specific directory without
allowing access to .htaccess files, that would be very difficult.
One idea similar but not quite like Tim's suggestion would be to add a
tag parameter to Forbidden, and to require the exact same tag
parameter for a "forbidden off" to be effective.
<Directory />
Forbidden tag=paths
</Directory>
<Directory /srv/www>
Forbidden tag=paths off
</Directory>
<Files .ht*>
Forbidden tag=htaccess
</Files>
<If ! %{HTTP_METHOD} -in { "GET", "POST", "HEAD" } >
Forbidden tag=methods
</If>
Then a
<If ! %{HTTP_METHOD} -in { "GET", "POST", "HEAD" } >
Forbidden tag=methods off
</If>
would do the right thing.
If we don't offer a wildcard 'Forbidden tag=* off', then the
possiblity for misguided FAQs to cause security issues would be
limited. Not specifying a tag would imply tag=default and not tag=*.
Of course, instead of doing this for a new Forbidden tag, we could do
this for all authz, too.
<Files .ht*>
<AuthTag htaccess>
Require all denied
</AuthTag>
</Files>
Authz directives would then only be merged within their own tag.
Maybe requiring to define the possible tags before use would be a good
idea to catch typos. And allowing to define which of these may be used
in .htaccess would be good, too. Probably some other name than 'tag'
would be better. Scope? Tier?
I haven't though about how easy this would be to implement in a
performant way, though. And it would increase the complexity of the
configurations quite a bit. But it would make it easier to avoid
accidental security problems.
