Poor symlinks at DreamHost
DreamHost has once again introduced changes (Apache upgrade?) to symlink handling.
Now the option -SymLinksIfOwnerMatch is plainly shutting your WordPress (or any other RewriteRules-based) site down, so you have to remove it from .htaccess to have the site up again.
Why -SymLinksIfOwnerMatch?
Symlinks in general is one of the most powerful of UNIX powertools.
In a shared webhosting environment there is a nice use case for symlinks aimed at improving website’s security.
The concept is very simple:
- run the website as a certain UNIX user,
- while having website files owned by another UNIX user.
In this type of setup if a hacker finds a vulnerability in your site’s framework they’ll have hard time doing any damage to the website files because they won’t own them.
Symbolic links are not strictly necessary here, but they make such a setup more useable:
- website’s “running” user’s directory is mostly empty having only the link pointing to
- the webroot directory located in the “owning” UNIX account, who may have FTP or other type of access to the files for convenient management.
To facilitate this in a classic Apache webserver one just puts +FollowSymLinks option into .htaccess and that’s all. All was well for ages until couple years ago DreamHost (or Apache – I didn’t actually investigate this) out of the blue decided that it is bad to symlink to someone else’s files.
Fortunately, there appeared another option, which is – you guessed right – -SymLinksIfOwnerMatch.
End of -SymLinksIfOwnerMatch era
Today one of my sites heavily relying on UNIX symbolic links in its operation has become unavailable displaying “Forbidden” page.
Apparently -SymLinksIfOwnerMatch has changed its semantics now meaning that RewriteRule’s are disabled while this option is in effect. I had to remove the option and copy files around once again to make them owned by all the (im-)proper accounts. Half a day of a downtime.
The downgrade
It is quite strange – with all the highly qualified staff DreamHost has got, they once again failed to warn about symlink handling change and once again making it more difficult to:
- Users – to secure their sites against attacks we’ve seen recently at DreamHost shared servers, and
- DreamHost themselves – by wasting disk space due to symlinks usage hurdles and by making their servers easier targets for spammers.