<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is a complex topic. I thought I would provide some details to help people to decide how they want to configure their boxes.</div><div class=""><br class=""></div><div class="">These settings enable a number of tweaks at an Apache level globally across all vSites. I did talk to Michael about possibly making them configurable at a site level. If I remember correctly, Michael advised they can only be set at an IP address level, not a vsite level.</div><div class=""><br class=""></div><div class="">Firstly, the “All” setting. I won’t discuss this… Turning on All is the same as ticking all boxes in that category. I will focus the discussion instead on the other settings that are not enabled by default.</div><div class=""><br class=""></div><div class="">1. Options: SymLinksIfOwnerMatch: This setting is not enabled by default. BUT, FollowSymLinks is enabled. If you were to turn on this setting, there is a zero additional security exposure or risk if FollowSymLinks is already turned on. In my opinion, it is smarter to turn this on - and disable FollowSymLinks… but thats another story.</div><div class=""><br class=""></div><div class="">2. AllowOverride: Options: This is more complex… Lets deep dive.</div><div class=""><br class=""></div><div class="">AllowOverride settings determine what stuff can be changed in a .htaccess file. What is a best practice setting? The Apache documentation says:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><p class="line867" style="margin: 0px 0px 8px; padding: 0px; border: 0px; font-size: 13px; line-height: 1.5; font-family: Ubuntu, 'Ubuntu Beta', 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif; vertical-align: baseline; color: rgb(51, 51, 51);"><span style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; line-height: 1; font-family: inherit; vertical-align: baseline;" class="">In general, you should never use .htaccess files unless you don't have access to the main server configuration file. There is, for example, a prevailing misconception that user authentication should always be done in .htaccess files. This is simply not the case. You can put user authentication configurations in the main server configuration, and this is, in fact, the preferred way to do things."</span></p></div><div class=""><p class="line867" style="margin: 0px 0px 8px; padding: 0px; border: 0px; font-size: 13px; line-height: 1.5; font-family: Ubuntu, 'Ubuntu Beta', 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif; vertical-align: baseline; color: rgb(51, 51, 51);"><span style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; line-height: 1; font-family: inherit; vertical-align: baseline;" class="">".htaccess files should be used in a case where the content providers need to make configuration changes to the server on a per-directory basis, but do not have root access on the server system. In the event that the server administrator is not willing to make frequent configuration changes, it might be desirable to permit individual users to make these changes in .htaccess files for themselves."</span></p></div></blockquote><div class=""><p class="line867" style="margin: 0px 0px 8px; padding: 0px; border: 0px; font-size: 13px; line-height: 1.5; font-family: Ubuntu, 'Ubuntu Beta', 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif; vertical-align: baseline; color: rgb(51, 51, 51);"><span class="anchor" id="line-15" style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; line-height: 1; font-family: inherit; vertical-align: baseline;"></span></p><p class="line867" style="margin: 0px 0px 8px; padding: 0px; border: 0px; font-size: 13px; line-height: 1.5; font-family: Ubuntu, 'Ubuntu Beta', 'Bitstream Vera Sans', 'DejaVu Sans', Tahoma, sans-serif; vertical-align: baseline; color: rgb(51, 51, 51);"><span class="anchor" id="line-17" style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; line-height: 1; font-family: inherit; vertical-align: baseline;"></span></p></div><div class=""><span style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; line-height: 1; font-family: inherit; vertical-align: baseline;" class=""><br class=""></span></div><div class="">If all of your websites are under your control, leave it off and go do your settings in include files as suggested by michael /etc/httpd/conf/vhosts/siteX.include. What about web hosting providers? What is the risk? What does the Options directive in .htaccess allow you to do anyway?</div><div class=""><br class=""></div><div class="">The Apache documentation is here…</div><div class=""><br class=""></div><div class=""><a href="https://httpd.apache.org/docs/current/mod/core.html#allowoverride" class="">https://httpd.apache.org/docs/current/mod/core.html#allowoverride</a></div><div class=""><br class=""></div><div class="">In simple terms, this setting will allow changing options like the ones that are all enabled by default. Eg FollowSymLinks, Includes, Indexes, MultiViews, SymLinksIfOwnerMatch. Looking at all of the above, AllowOverride options sounds reasonably safe. Providing this access allows your clients flexibility without having to open tech support cases to do weird stuff… but there is one more thing that is not covered above</div><div class=""><br class=""></div><div class=""><a href="http://php.net/manual/en/configuration.changes.php" class="">http://php.net/manual/en/configuration.changes.php</a></div><div class=""><br class=""></div><div class="">These changes allow your customers to change in .htaccess files settings relating to PHP. Sometimes, their web applications need settings to be tweaked.</div><div class=""><br class=""></div><div class=""><a href="http://php.net/manual/en/ini.list.php" class="">http://php.net/manual/en/ini.list.php</a></div><div class=""><br class=""></div><div class="">The above is a list of all current PHP settings that can be changed. If you have AllowOverride Options enabled, your clients can change everything that is not listed as PHP_INI_SYSTEM in the list above. The biggest risk in my opinion relates to open_basedir. If you have set a restriction in your gui that prevents a user from going to stuff outside their home directory, they can bypass this setting in .htaccess. The good news is that this setting was invented to protect websites that don’t run without suphp or similar. If you use suphp, mod_ruid2, or FPM, there is another layer of protection that prevents access or modification to files based on file system permissions.</div><div class=""><br class=""></div><div class="">What is the ultimate recommendation? What do I do myself? The most important setting is to use suphp, mod_ruid2 or FPM for all PHP enabled sites. By doing that, the worst case scenario in that case is they can create an exposure that will affect their own site… but the rest of your server is still protected. All of my client sites are protected in this way. Therefore, I am comfortable to enable AllowOverride Options. It makes my life easier, allowing clients to do the tweaks they need without hassling me.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Greg.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 25 Jun 2016, at 4:20 AM, Chuck Tetlow <<a href="mailto:chuck@tetlow.net" class="">chuck@tetlow.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type" class="">
<meta content="OPENWEBMAIL" name="GENERATOR" class="">
<div bgcolor="#ffffff" class="">
That's what I'm afraid of Michael.
<br class="">
<br class="">That "AllowOverride - ALL" is a server-wide setting. And wouldn't that open it up to possible vulnerabilities, maybe in other older-software sites on the server? We've got some customers who are running 10 year old PHP sites on our newer BlueOnyx servers - and having problems already.
<br class="">
<br class="">Not to mention... At least three or four times a year - someone finds & exploits a vulnerability in one of our customer's sites or users accounts. Then the server is sending out tons of SPAM, getting blacklisted, and the other users on it are bitching that they can't send e-mail.
<br class="">
<br class="">So I'm VERY leery of activating any abilities that might allow a exploit in the future. And I'd read that the AllowOverride option could do exactly that.
<br class="">
<br class="">
<br class="">Chuck
<br class="">
<br class=""><font size="2" class="">
<br class="">
<br class=""><b class="">---------- Original Message
-----------</b>
<br class="">
From: Michael Stauber <<a href="mailto:mstauber@blueonyx.it" class="">mstauber@blueonyx.it</a>>
<br class="">
To: BlueOnyx General Mailing List <<a href="mailto:blueonyx@mail.blueonyx.it" class="">blueonyx@mail.blueonyx.it</a>>
<br class="">
Sent: Fri, 24 Jun 2016 12:55:31 -0500
<br class="">
Subject: [BlueOnyx:19762] Re: Enabling the rewrite module in Apache config
<br class="">
<br class="">> Hi Chuck,
<br class="">>
<br class="">>
> Does anyone have any experience with, or recommendations on enabling the
rewrite
<br class="">>
> module in the Apache config?
<br class="">>
<br class="">>
It's enabled by default on all BlueOnyx versions. You can verify it this
<br class="">>
way:
<br class="">>
<br class="">>
[root@5209r ~]# /usr/sbin/httpd -M|grep rewrite
<br class="">>
rewrite_module (shared)
<br class="">>
<br class="">>
So you (or your site developer) should be able to use it.
<br class="">>
<br class="">>
If you want to create your own rewrite rules, they can either go into
<br class="">>
the Vsites include config file:
<br class="">>
<br class="">>
/etc/httpd/conf/vhosts/siteX.include
<br class="">>
<br class="">>
... where they won't be overwritten by any changes. Or they could go
<br class="">>
into .htaccess files in /web or subdirectories of your actual Vsite.
<br class="">>
<br class="">>
For some of these functions to work in .htaccess files you need to allow
<br class="">>
them first via the GUI. For that see "Server Management" /
"Network
<br class="">>
Services" / "Web" and see under "Options" and
"Allow Override". You may
<br class="">>
have to tick both "All" checkboxes.
<br class="">>
<br class="">>
--
<br class="">>
With best regards
<br class="">>
<br class="">>
Michael Stauber
<br class="">>
_______________________________________________
<br class="">>
Blueonyx mailing list
<br class="">>
<a href="mailto:Blueonyx@mail.blueonyx.it" class="">Blueonyx@mail.blueonyx.it</a>
<br class="">>
<a target="_blank" href="http://mail.blueonyx.it/mailman/listinfo/blueonyx" class="">http://mail.blueonyx.it/mailman/listinfo/blueonyx</a>
<br class=""><b class="">------- End of Original Message
-------</b>
<br class="">
</font>
</div>
_______________________________________________<br class="">Blueonyx mailing list<br class=""><a href="mailto:Blueonyx@mail.blueonyx.it" class="">Blueonyx@mail.blueonyx.it</a><br class="">http://mail.blueonyx.it/mailman/listinfo/blueonyx<br class=""></div></blockquote></div><br class=""></body></html>