Bug 52439 - It should be possible to treat errors in .htaccess as nonfatal
Summary: It should be possible to treat errors in .htaccess as nonfatal
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.4.10
Hardware: PC All
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-09 02:50 UTC by Nick Kew
Modified: 2020-12-24 20:44 UTC (History)
2 users (show)



Attachments
Honour nonfatal overrides in Options (804 bytes, patch)
2013-08-28 12:43 UTC, Dave
Details | Diff
Honour nonfatal on Options All specific case (1.47 KB, patch)
2016-08-02 12:24 UTC, Alexis Maiquez
Details | Diff
Honour nonfatal unknown for options all (2.06 KB, patch)
2016-08-03 11:15 UTC, Alexis Maiquez
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Kew 2012-01-09 02:50:46 UTC
Any syntax error in httpd.conf is treated as fatal, causing httpd to refuse to startup and print an error message to help the sysop identify the error.

Errors in a .htaccess file are treated as fatal to the request, causing a 500 error.  This is less useful, and in some cases it may be more appropriate to ignore .htaccess syntax errors and merely log a warning.  This alternative is particularly useful where a sysop wants to support users dropping in .htaccess files packaged with some-application, which might cause unnecessary errors due to conflict with AllowOverride settings, or more rarely a directive from a module that's not included.

It should be possible for a sysop to configure httpd to treat errors in .htaccess as non-fatal warnings, and simply ignore (but log) the offending directives.
Comment 1 André Malo 2012-01-09 15:09:06 UTC
That can lead to security related problems (e.g. if the .htaccess contains some authentication or otherwise restrictive directives). Since we cannot know that - 500 is the safe fallback then.
Comment 2 Nick Kew 2012-01-09 15:24:10 UTC
That's for the server admin to determine.  The current situation can also lead to security issues where AllowOverride.

Posting an explanation from someone who runs hosting and is concerned about Options:

- We currently disallow FollowSymLinks due to security reasons
- We do allow SymLinksIfOwnerMatch which is enough for most CMS and other systems used on our platform to work
- Many systems ship with .htaccess files containing "Options +FollowSymLinks" or "Options None" causing errors
Comment 3 Nick Kew 2012-01-09 15:35:50 UTC
I also committed a trunk patch for this in r1229021 .
Comment 4 André Malo 2012-01-09 19:27:15 UTC
Yes, I know, I was bitten by such an admin failure already (as someone who used .htaccess), hence my statement. You've just opened another vector for that.

Given your explanation - I'm not sure what problem the patch is actually going to solve. The user now won't even get an error [1] and is wondering why it doesn't work.

(Oh there are even docs somewhere suggesting to write garbage into the .htaccess file in order to check if the files are read at all).

[1] Yes, especially in bigger hosting environments, the user doesn't have access to the error log.

Well, *shrug*.
Comment 5 Jaroslaw 2012-03-01 09:34:43 UTC
Hello Kew,

We've just upgraded to 2.4.1 to test your patch.

Your patch doesn't resolve issue given by you (from someone who runs hosting).
I run hosting too. I've such config in users' virtualhosts:

<Directory /home/someone/public_html>
AllowOverride Nonfatal=All AuthConfig FileInfo Indexes Limit Options=Indexes
Options -Includes -Indexes +ExecCGI +SymLinksIfOwnerMatch
</Directory>


And now just try to give some samples to /home/someone/public_html/.htaccess


Optionz +FollowSymlinks or sth like that doesn't show any error (good, patch is working)


Options +FollowSymlinks still gives me internal server error 500 


So IMHO patch is useless in the situation you quoted or I use it in the wrong way.
Comment 6 Dave 2013-08-28 12:43:13 UTC
Created attachment 30775 [details]
Honour nonfatal overrides in Options

set_options needs to honour the nonfatal flags - suggest something like this, which would satisfy the use case given.
Comment 7 Jarrod Makin 2015-10-19 22:36:47 UTC
Tried the patch today, confirmed it works, far better than having websites serve Internal Server Errors due to clashing options.

Also, since documentation states that this IS the way the server behaves, the server should behave this way, or the documentation should be altered.
Comment 8 apache.tracker 2016-04-29 14:12:00 UTC
We have also been testing the patch in our environment and I can confirm it working.
Is there an update on this getting merged into the stable release?
Comment 9 Alexis Maiquez 2016-08-02 12:24:19 UTC
Created attachment 34093 [details]
Honour nonfatal on Options All specific case
Comment 10 Alexis Maiquez 2016-08-02 12:28:57 UTC
There's an edge case with the Dave's patch involving Options All and SymLinksIfOwnerMatch

If you add Options All to the .htaccess and have any rewrite rule and/or symbolic links on the filesystem apache will stop serving those files and send status 500 (and remove every option already enabled in server configuration).

This does look like a bug, but there is no specific documentation on how the server should behave in such situations, so the patch I've attached enables everything that is not disabled by a prior AllowOverride.

P.S: Sorry for the double post, didn't notice the file was being added without any comment at all.
Comment 11 Alexis Maiquez 2016-08-03 11:07:14 UTC
Comment on attachment 34093 [details]
Honour nonfatal on Options All specific case

--- httpd/server/core.c	2016-06-14 01:08:08.000000000 +0200
+++ httpd/server/core.c	2016-08-03 13:00:56.472620572 +0200
@@ -1971,13 +1971,38 @@
             all_none = 1;
         }
         else {
-            return apr_pstrcat(cmd->pool, "Illegal option ", w, NULL);
+            if (cmd->override & NONFATAL_UNKNOWN) {
+                opt = 0;
+                ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server, "Unknown Option %s in line %d of %s.",
+                    w, cmd->directive->line_num, cmd->directive->filename);
+            } else {
+                return apr_pstrcat(cmd->pool, "Illegal option ", w, NULL);
+            }
         }
 
         if ( (cmd->override_opts & opt) != opt ) {
-            return apr_pstrcat(cmd->pool, "Option ", w, " not allowed here", NULL);
+            if (cmd->override & NONFATAL_OVERRIDE) {
+                ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server, "Option %s not allowed in line %d of %s.",
+                    w, cmd->directive->line_num, cmd->directive->filename);
+
+                /* special case for Options All, we might want to enable every possible (and allowed) parameter */
+                if (opt != OPT_ALL) {
+                    first = 0;
+                    continue;
+                } else {
+                    /*
+                     * OPT_ALL doesnt include OPT_SYM_OWNER but its important to enable that one too
+                     * also take in mind that Options All does not have + or - so it'll be added to the already enabled options
+                     * this means it'll enable everything that is allowed to be overriden
+                     */
+                    opt = (OPT_ALL | OPT_SYM_OWNER) & cmd->override_opts;
+                }
+            } else {
+                return apr_pstrcat(cmd->pool, "Option ", w, " not allowed here", NULL);
+            }
         }
-        else if (action == '-') {
+
+        if (action == '-') {
             /* we ensure the invariant (d->opts_add & d->opts_remove) == 0 */
             d->opts_remove |= opt;
             d->opts_add &= ~opt;
Comment 12 Alexis Maiquez 2016-08-03 11:15:42 UTC
Created attachment 34099 [details]
Honour nonfatal unknown for options all

If an option is not correct it does nothing. Also fixes a small mistake in attachment 34093 [details] which, although it was working, wasn't correct at all.
Comment 13 David Spector 2020-12-24 20:44:38 UTC
I would suggest that the real solution to the current lack of debugging support in Apache for both syntactic and semantic errors in config and .htaccess files is simple: either add a directive to log a given string or expression, or add a directive to call a PHP file with a given string or expression as an argument. Either way, configuring Apache would become dramatically easier, on par with writing a computer program or a website, both of which have debugging aids (detailed error messages with line numbers for compiled programs, and Developer Tools for website programming). As to security, writing a little data to the error log is usually not a security issue, but in cases where it is considered a security issue, just add a SAFE or SECURE MODE to Apache which will disable such new directives. So simple, I could almost do it myself, if Apache were easy to modify and build, which I highly doubt, its being an older product.