http://bugzilla.suse.com/show_bug.cgi?id=939829
http://bugzilla.suse.com/show_bug.cgi?id=939829#c8
--- Comment #8 from Petr Gajdos
This happens if your are using mod_access_compat. When that is enabled, you *must* use the 2.2 syntax and you'll get a 403 if trying to use the 2.4
*Generally*, that is not exactly true as far as I know. If both authz_core and access_compat are loaded, you can use either system you want.
Require ... syntax. It might work to use both at once but that gets confusing (and possibly undefined if they conflict!).
You can even use both of them together, but the result has to be consistent, that is: access is allowed if both systems allow. If at least one forbids, access is forbidden. See 881506 comment 18.
Because of this, relying on a version check is insufficient, as 2.4
Yes, thats true (because of access_compat), nevertheless ..
w/mod_access_compat behaves like 2.2. Adding wrappers like <IfModule mod_access_compat.c> Order allow,deny Allow from all </IfModule>
Require all granted </IfModule>
.. whether this will work depends also on which syntax is used previously. If mod_access is loaded but new syntax forbid into this dir, this won't work. Also note that access_compat is not present in sle11. So I would disclaim my comment 1 for distros older than Tumbleweed.
e.g. default-server.conf. I would suggest backporting the fix to 13.1/13.2, but that's beyond the scope of this bug, and the other one is closed, so ???
In my opinion, this is too invasive change to backport, I am afraid. The situation on newly installed distros (not upgrades!) is as follows: sle11 no access_compat httpd.conf (Deny for /): old syntax 13.1 access_compat static httpd.conf (Deny for /): new syntax 13.2 access_compat static httpd.conf (Deny for /): new syntax Tumbleweed access_compat shared, not loaded by default httpd.conf (Deny for /): old syntax when access_compat loaded, new syntax otherwise So everywhere in supported openSUSEs we can assume that new syntax should be preferred. I tend to agree with Lars to use upstream solution. Currently I do not se a way to catch all possibilities. -- You are receiving this mail because: You are on the CC list for the bug.