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? On Mon, Jun 10, 2013 at 5:17 PM, Stefan Fritsch <s...@sfritsch.de> wrote: > 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? > -- Eric Covener cove...@gmail.com
