httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: "Forbid" directive in core?
Date Sun, 29 Sep 2013 09:09:23 GMT
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.

Mime
View raw message