When specifically enabling +SymLinksIfOwnerMatch globally and then disallowing it from being overridden with AllowOverride, setting +SymLinksIfOwnerMatch in a .htaccess file causes an internal server error. This isn't intuitive - setting an option which is already enabled, even if it's not permitted to be overriden, should not cause an error. To reproduce, set this globally: <Directory "/some/directory/path"> Options +All +IncludesNOEXEC -Indexes +SymLinksIfOwnerMatch AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,FollowSymLinks </Directory> Then create a .htaccess file in /some/directory/path that contains: +SymLinksIfOwnerMatch No override is occurring as the option being set is already set, yet we get an error. This behaviour causes all default installs of Drupal to give ISE's when the global configuration is in place. The purpose of the global configuration, in case it isn't clear, is to enforce +SymLinksIfOwnerMatch and to cause an ISE if -SymLinksIfOwnerMatch is set in a .htaccess file. Thanks, Vince Stratful.
Why was this switched to enhancement? It's clearly a bug, not a feature request. Thanks, Vince Stratful.
(In reply to comment #1) > Why was this switched to enhancement? It's clearly a bug, not a feature > request. IMO it is an enhancement to make it any smarter, taking into consideration the doc vs. the behavior AllowOverride options= doesn't control the effective values, it controls which literal options can appear in the Options directive. For this same reason, you also can't enforce SymlinksIfOwnerMatch by not allowing an override of "SymlinksIfOwnerMatch", because once you delegate any other single option the user can just omit SymlinksIfOwnerMatch and use the non-relative syntax. SymlinksIfOwnerMatch tends to pop up as a problematic case because it's one of the few options you "turn on" to limit something, but this configuration option does not let you enforce what "stays on".
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.