[thelist] PHP Perl Apache security

Aredridel aredridel at nbtsc.org
Sun Jul 20 09:57:33 CDT 2003


> open_basedir scenario:
> PHP can be jailed in a domain by adding
> php_admin_value open_basedir "/root/domain/"
> to the domain's virtualhost table. Doing so on all virtualhosts keeps PHP 
> from wandering out of the domain it resides in. Problem: that does not 
> change the fact that PHP still needs world write permissions on a target 
> file within that domain path and setting that permission invites Perl from 
> another domain to write to PHP's target file. Even if suExec is running, a 
> Perl script in another domain can write to this domain's PHP target file 
> because the file has world write permission.

The mod_proxy scenario:

You run a separate copy of apache for each vhost (at least each that
need it), with a different User directive (I reccomend /not/ the same as
the user who owns it: instead, each user gets two IDs -- user and
user.http -- that way, they can keep their files isolated from their own
scripts, which is Good Security, the same as running HTTPD as root is
bad.

Then, you set up mod_proxy on the /main/ instance of Apache to map each
user's URL-space into the other instance of apache, running on another
port or another IP -- you can use IPs in the 127.*.*.* block -- that's
what they're for, if your OS supports it (Linux does).

That way is a good one for the ultimate power, but it's heavy on
resources, though not /actually/ that bad since all the executable code,
despite running multiple copies, only gets one copy of the code pages in
RAM, because of Linux >= 2.0's memory handling.  If you set apache to
only prefork a few daemons per user (adjust as their site load grows),
you don't end up too badly off, resource-wise.  It's probably lighter
than running PHP as a CGI, because you save on PHP's init time, and the
forking, and PHP shares more data structures between it's instances as a
module than it does as a CGI.

It also allows you to let a user have complete control of their apache
process -- let them edit httpd.conf if they like!  Allow them to install
mod_ruby, mod_mp3, whatever.  You don't have to care nearly so much,
because their stuff can't touch anything else on the VHost box, since
their web-writable files are owned by user.http, and their files are
owned by user -- complete write access isolation.

Ari



More information about the thelist mailing list