While trying to secure a site (LAMP & WordPress) on a shared host that had been victim of a pharma hack; I was advising the site owner to follow wordpress' best practices from here http://codex.wordpress.org/Hardening_WordPress and there is this command for making files read-only for everyone except the owner

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

But I ran <?php echo exec('whoami'); ?> and discovered that the apache user is running as the same user that the site-owner has for SFTP. So Apache is running as the file owner.

This looks to me like a massive security issue because anything the site owner can do, Wordpress plugins could do!

Am I correct that this is something the host should fix? If they are resistant, what can I say to persuade them, and is this a big enough problem to warrant changing hosts?

update : For clarity I am talking about protecting the website from itself effectively. To stop holes in plugins being used to write/edit code on the server, if the webserver is running as the site owner, then plugins could be manipulated into installing arbitrary code and altering the .htaccess

update 2: when I said "security hole", I might have meant "vulnerability"


Not necessarily. It's a common approach to run separate apache processes under regular user accounts, especially on shared hosts. This is not a security issue per se. Instead, it might be the wrong security model for your requirements. If you need your account for important other stuff than web serving as well, then you should isolate your web presence completely anyway.

You can ask them if they have a different configuration available (sometimes they do).

Edit: To clarify. It's an issue for your particular use case. How? Take the view of the hoster for a minute: Here, they want to isolate their users a.k.a. customers from each other (and the rest of the system), hence running the processes under the according user accounts. Running them all under the same account (for example, www-data), would mean breaking into one customer site the data of the other customers to be compromised as well.

You, on the other side, and I agree with you, need to isolate the rest of your data against your web presence.

There are many possible solutions to this problem, one, like you suggested, giving each customer two user accounts. Or, a real good apache/cgi configuration isolating the webserver to a particular fixed sub-directory in the user's home with no chance of breaking out (which is what was done at one employer I worked at in the past). Best coordinate with your hoster.

  • Any ideas why the standard default isn't "CodeMonkey" for SFTP and "CodeMonkey-www" for apache? how is giving apache full access not a security issue, surely it means we can't protect ourselves against 3rd party plugin mistakes? – CodeMonkey Jul 9 '13 at 17:22
  • let me elaborate and update my answer... – Roman Jul 9 '13 at 20:00
  • I disagree that running wordpress is my "particular use case" you make it sound like I am running some niche custom software, they claim over 27M downloads and counting, and anything with a plugin ecosystem, like joomla, phpbb etc will be in a similar situation. Maybe I wasn't clear in my original Q, locking the apache user to a subdir has almost certainly been done on the host, but this security hole - as I see it - doesn't protect the website from itself – CodeMonkey Jul 10 '13 at 8:06
  • It wasn't my intention to make it sound like this, and it answered the Q - does this cause a security hole?: not necessarily, as it depends on what you need. It does for you. SO - best ask a new question and ask how you protect your site correctly. We want to avoid scope creep. – Roman Jul 10 '13 at 9:17
  • might be an issue with my terminology, no harm done :) – CodeMonkey Jul 10 '13 at 10:25

I apparently have a different view than Roman, but I think it is a major problem that many PHP sites run as the owner of the *.PHP files (often www-data). This is even required if you want to be able to use features like Wordpress's auto-update, because the webserver needs to write PHP files.

PHP sites are going to have leaks that allow you to inject code in their files, that's pretty much a given. So you want to protect against that. Even setting to read-only often won't work, because the directory is still writable, and when the user owns the file, read-only can simply be overridden.


set open_basedir in php.ini for this user. Use fcgid. So, this site will be protected from itself. Also, use disable_functions to disable shell access etc.

That's all :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.