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 Mon, 10 Jun 2013 21:17:50 GMT
On Monday 10 June 2013, Plüm, Rüdiger, Vodafone Group wrote:
> > > I'd like to add an immutable Forbid directive to the core and
> > > use it in some places in the default configuration instead of
> > > "require all denied".
> > > 
> > > http://people.apache.org/~covener/forbid.diff
> > > 
> > > This protects from a broad <Location or <If being added that
> > > supercedes Directory/Files.
> > > 
> > > I thought someone might object to the duplication w/ AAA or the
> > > presence in the core, so opting for RTC.
> >
> > 
> >
> > Why indeed in core?
> 
> Indeed, why in core?

Maybe mod_authz_core would be more appropriate?

> And what is bad about "require all denied"?

That it is too easy to override by accident.

Actually, mod_allowhandlers in trunk allows 

  SetHandler forbidden

which more or less does what Forbid does (unless one overrides the 
Handler later on). But that's even more confusing than a separate 
Forbid.

I am in favor of adding something that denies and is difficult to 
override by accident. But maybe the combination

  Require all denied
  AuthMerging and inherit

would do the trick, denoting that later sections are merged with and 
unless AuthMerging is set explicitly. But I guess it could still 
happen that this would be overriden by accident by an "AuthMerging or" 
later on. Another possibility would be

  AuthMerging immutable

stating that sections merged later would be ignored. But I can't think 
of any sane usage except with "require all denied". So maybe the 
Forbid is enough?


Mime
View raw message