Comment # 19 on bug 881506 from Petr Gajdos

(In reply to Jan Matejek from comment #18)
> the trouble is that it's not "old syntax" vs "new syntax", but "old module"
> (access_compat) vs "new module" (authz_core), and we have both enabled
> so every request goes through TWO access control layers, and must pass BOTH
> in order to work.
> /i don't know if this is true on implementation level, but it is consistent
> with observed behavior/
> 
> in other words, you can use *either* of the two syntax variants to *disable*
> access, but you have to use *both* to reliably *enable* access.

Very valuable explanation for me, thanks! I tested it with success, too. Maybe
small addition; it looks like it is enough permission from one layer if second
layer do not forbid access:

<Directory />
  Options None
  Require all denied
</Directory>

DocumentRoot "/srv/www/htdocs"
<Directory "/srv/www/htdocs">
  Options None
  Require all granted
</Directory>

<Directory "/srv/www/htdocs/foo">
  Options None
  Allow from all
</Directory>

For /srv/www/htdocs and /srv/www/htdocs/foo I get 200. In the contrary, when I
Deny from all for /, I get 403 from /srv/www/htdocs and 200 for
/srv/www/htdocs/foo.

> ---
> <IfModule mod_access_compat.c>
>   Order allow,deny
>   Allow from all
> </IfModule>
> <IfModule mod_authz_core.c>
>   Require all granted
> </IfModule>
> ---
> (note that we use the "authz_core is enabled" condition, as opposed to
> "access_compat is disabled" which is now broken in gitweb. that's a gitweb
> bug)

Looks good! When both modules loaded, then both layers are used. 

If I understand correctly, if we would not go for point 2. below, everything
under DocumentRoot would be accessible if both access_compat and authz_core
would be unloaded? If yes, then perhaps we should go for 2.

> 1. make mod_access_compat unloadable, and unloaded-by-default
> 2. optional but seems reasonable, make mod_authz_core static
> 3. let default configuration files use the authz_core (Require *) syntax. we
> have this now, no change is required
> 3. update all packages that drop configs to use the conditionals shown above
> 4. create mod_access_compat.conf that is included when mod_access_compat is
> enabled, that "punches holes" in default authz_core configuration
> 
> With authz_core-based config, and access_compat enabled, some things already
> work "both ways": if you want to hide a directory that's accessible by
> default, you can use either syntax, as long as you're consistent in rules
> under that particular directory.
> 
> The missing step is enabling access to anything outside /srv/www/htdocs,
> i.e., all the things that are inaccessible by default.
> 
> There are around 20 Require directives in the default config, most of which
> are "Require all granted". in order to avoid having conditionals in each of
> those 20 places, we can move the respective "Order allow,deny; Allow from
> all" directives into the mod_access_compat.conf file, thus enabling
> everything for access_compat that's already allowed for authz_core.
> The last step is to put "Order deny, allow; Deny from all" for the root
> directory. But this is the part that breaks things: if we do this, we have
> to enable both authz_core and access_compat everywhere. So instead, we
> declare that mod_access_compat **switches to legacy mode**, and specify
> "Require all granted" for root (and the other three places where authz_core
> restricts access), giving access control over to access_compat completely.
> When configured this way, "Order allow,deny; Allow from all" is sufficient
> to allow access, and legacy configuration files work again.

Hmm, it sounds like an interesting idea if I got it correctly. Nevertheless am
I right that when one would have to change or add some access rule then he
would have to go to into regular configuration and then also to
mod_access_compat.conf to change the 'compat config mirror'?

Despite what I have said you yesterday; if we will decide to support old
syntax, I would vote instead for letting it go along with new syntax with
conditionals, if there is no benefit of the mod_access_compat.conf-suggestion I
could have missed.