Comments on: Running PHP on Shared Hosting

By: John

John — Wed, 16 Jan 2008 23:01:23 +0000

In that "200gb oversold plans" thread, Matt Heaton says if he has an account on your shared server:

"I will be able to not only list every "webable" file for every account on your server..."

Is that possible -- and if so actually due to mod_php being installed?

By: scotty

scotty — Wed, 11 Jul 2007 23:46:02 +0000

Ta. Fixed.

By: Anonymous

Anonymous — Wed, 11 Jul 2007 14:44:46 +0000

Error in table:
Performance High Medium Low
must be
Performance High Low Medium

By: Nicholas Orr

Nicholas Orr — Sun, 24 Jun 2007 08:33:21 +0000

I thought that. You could chroot everyone yeah? One host I went with did this. that effectively allows multiple apache process’ yeah?

By: scotty

scotty — Sun, 24 Jun 2007 07:39:19 +0000

That sounds like mpm-itk which Nicholas has mentioned before…

By: Anonymous

Anonymous — Sat, 23 Jun 2007 20:27:00 +0000

At the hosting ISP we work at, we use mod_php on shared hosting and it's highly secure. We came up with a way where each user has their own apache instance and anything, whether it be mod_php, server-parsed, etc, are executed as their own unique uid rather than "nobody" or anything shared. I can't comment on it more, though!!

By: svcommunity

svcommunity — Tue, 29 May 2007 17:44:27 +0000

Nice Article, i've always used mod_php with safe mode ON and never had any problems, i guess im lucky with the scripts i choose to use.

Im going to read the "fight back against those 200Gb oversold plans" it looks interesting :p

By: Schraalhans Keukenmeester

Schraalhans Keukenmeester — Sun, 27 May 2007 12:04:32 +0000

Another weak spot in many shared environments (using mod_php): the syscall related functions like exec(), passthru(), popen(), proc_open(). Rarely are these excluded from use in php.ini, and especially if safe_mode + safe_mode_exec_dir aren't set this opens up a can of worms. I am not even sure the backtick operator can be disabled at all if safe_mode=off. (it might though)

To hide sensitive data one might resort to including or fopen-ing remote files (if ISP allows it) which only are served from the proper ip, referer, request_uri etc. Even that's not secure, since all those details can be spoofed in the header, but combined with a strict firewall ruleset on the second host (e.g. a local machine) most can be kept out. Better than returning an error if the request doesn't match the criteria would be to return a version of the requested files containing bogus values.

In short: php_mod is not really suited for secure shared hosting. Period.

By: Nicholas Orr

Nicholas Orr — Fri, 13 Apr 2007 01:35:43 +0000

Umm.

I should have previewed my post, information got chopped off do to angle brackets...

Just to clarify:

I run each vhost as apache:apache(username) (ie apachenorr)

I think everything else makes sense now that the group I run as is not common :)

By: scotty

scotty — Thu, 12 Apr 2007 23:04:35 +0000

Nicholas -- sorry I actually did not know anything about mpm-itk. I just had a look and think it is a good solution. Obviously it has a few issues:

Apache running as root before vhost is determined.
Apache forks to execute each request, and the process is not reused.

Neither are big issues I think in shared hosting environment. I'll take a closer look at this stuff.

With regular prefork MPM + mod_php, another user on the same server is running PHP scripts with the same privilege as you. So for every file you enable Apache to read, someone else can read it as well on the same server. chgrp apache + chmod g+w is not that useful as someone else's script is still running with GID=apache. Explicitly crippling PHP (safe mode + friends) is probably the only secure way for prefork MPM + mod_php.