Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8631
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 19 Mar 2004 14:23:13 -0800 (PST)
To: Ilia Alshanetsky <ilia@prohost.org>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <200403191709.29446.ilia@prohost.org>
Message-ID: <Pine.LNX.4.58.0403191413140.2205@thinkpad.lerdorf.com>
References: <61700.66.158.132.127.1079718509.squirrel@www.funio.com>
 <200403191641.18788.ilia@prohost.org> <Pine.LNX.4.58.0403191342520.2205@thinkpad.lerdorf.com>
 <200403191709.29446.ilia@prohost.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] new security related directive for php-4.3.4
From: rasmus@php.net (Rasmus Lerdorf)

On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:
> Thousands of users on a single machines at least half (probably more) use 
> dynamic scripts, would require some superb hardware and even then I very much 
> doubt it could be done effectively. It would be far more practical and 
> economical to have several cheaper servers with perhaps 100-300  (or less) 
> users each.

I am not arguing that.

> The bottom line that right now solutions do exist, Apache2 perchild MPM could 
> work

I suppose it could, but it doesn't.  Have you tried it?

> so will Fastcgi. There are also things like mod_become, mod_suid and 
> mod_diffprivs that can perform uid/gid changes for Apache1.
> 
> http://www.jdimedia.nl/igmar/mod_suid/
> http://www.snert.com/Software/mod_become/
> http://sourceforge.net/projects/moddiffprivs/
> 
> Unlike with PHP implemented 'security' controls these are much less trivial to 
> bypass.

And much more harmful once you do bypass them.  These rely on a config
where setreuid() can get you back to the root id after any http request.  
It is effectively equivalent to running your web server as root and has
the same disastrous consequences if hacked.  If you read the mod_suid page 
and README you will see disclaimers all over the place about how insecure 
this mechanism is.

Look, my preferred solution to this has always been to run multiple Apache 
servers behind a reverse proxy.  Every virtual host gets its own Apache 
instance running as that users own uid.  If you keep the Apache binary the 
same for all the hosts the memory requirements aren't even that excessive.  
You of course can't do thousands of hosts, but no mechanism can 
effectively do that anyway.  But you can surely do dozens or maybe even 
hundreds on a decent server.

But people still like the efficiency and convenience of a runtime 
open_basedir check.  It gets you 90% of the way there and it doesn't cost 
you that much.  Until there is a realworld alternative for folks, and no, 
nothing mentioned so far are realistic alternatives, I just don't see this 
demand going away.

-Rasmus