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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
