There are plenty of ways to make PHP secure for virtual hosting. I personally prefer a separate Apache instance for each virtualhost where each instance runs as that customer's own UNIX user id. Then standard Linux filesystem security can be applied.
A nice way to achieve this is to use a reverse proxy such as Squid out in front of your external port 80 and have something like SquidGuard direct requests to different ips/ports for the various virtual hosts. You get the added benefit of actually getting a fast cache sitting out in front of all your dynamic pages which speeds things up considerably. As far as I am concerned this is best way. But, you can also get pretty far with the standard open_basedir approach. I am a bit dismayed to hear you say that setting open_basedir for each virtualhost is a lot of work. Surely this is a 10-second awk script or even a vi macro that simply takes: DOCUMENT_ROOT /some/path and turns it into: DOCUMENT_ROOT /some/path php_admin_value open_basedir /some/path I also don't understand your readdir() issue. opendir() checks safe_mode and readdir() needs an opendir()-returned directory identifier to do anything. So unless your UNIX filesystem perms are completely wrong, you should not be able to write a filebrowser in PHP that goes through everyones' directories. Just like you would not be able to read the names of the session files in /tmp. As for the original question, yes, copy() is intentionally not going to work on uploaded files in safe_mode. However, you should be using move_uploaded_file() and that does work on uploaded files in safe_mode. In the end this entire problem needs to be solved at the web server level, not at the PHP level. Apache 2.0 will eventually have per-virtualhost user/group directives but we are still not quite there with it in terms of being a production-quality environment. -Rasmus On Sun, 13 Jan 2002, Daniel Lorch wrote: > Hi, > > > I'm administrating a server with many virtual hosts. To get rid of some > > security holes i enabled safe_mode. But after that php scripts weren't > > able to handle (read, move, copy, delete...) uploaded files and files > > which have been created by the script itself. > > mod_php is *NOT* suitable for virtual hosting, just nobody tells you. > You know that, Roland, I told you and you keep ignoring me. Your > customers just don't realize - mine do quite well and that's a pain > in the ass. > > the module is good, when you're running your own box and you need a > performance boost. forget the module, it's crap if you really care > about security/privacy. I'm not a professional in un*x security, but > even with my skill level it was easy finding dozens of holes in the > whole architecture. safe_mode doesn't actually cure the problem, it > just patches the most obvious issues. yes, you could turn OFF every > little function and make PHP absolutely useless, but that absolutely > doesn't make sense to me. > > just a couple of days ago a customer wrote me and told me that the > filenames of the sessions stored in /tmp/ are equal to the session-IDs. > GOOD. When you use sessions for authentication then everyone can > easily spoof you and log in as you. this is not a safe_mode issue, but > because all sessions belong to apache, everyone could write a > php-script which reads out these sessions and which sometime contain > sensitive data. the _user_ himself isn't able to read these sessions, > but apache just HAS to be, thats the problem. > > we use omail http://omail.omnis.ch/ that our customers are able to > administer their POP3 accounts. omail is an interface to vmailmgr > http://vmailmgr.org/ . this software runs as a local daemon and > requires the user password for every action taken, so omail HAS to > store the user password in the session. it's somehow encrypted (binhex > or something, doesn't matter. the sourcecode is open, you can easily > find out). > > somebody who now reads out these sessions would have everyone's > linux-login and password. nice. this wouldn't be a problem if these > sessions belonged to the actual user - which isn't the case with > mod_php. > > my workaround was to create /tmp/php_sessions/ with only +xw and -r so > the contents cannot be listed by anyone (not even apache). the > sessions ARE still readable by apache (and thus everyone who is able > to code PHP), but you first have to guess the ID, which is pretty > difficult, as you know. > > uuh and gread, readdir isn't limited by safe_mode either (wouldn't make > sense, if it was. Oddly enough that 'chdir' IS limited by safe_mode). > I can easily look into all customers accounts with a filebrowser I > quickly wrote in PHP. I cannot actually *read* these files, but I can > still look into their directories. I know there is a directive called > open_basedir, but I still want to be able to read out /proc/ and other > interesting directories (such as displaying the current CPU temperature > on my website and other silly stuff). I was thinking of setting the > open_basedir for every customer seperately in the <virtualhost> > directive, but that is quite a lot of work. > > and yes, you completely have to restrict all shell-commands. We're > running http://www.imagemagick.org/ because GD just doesn't suffice > our customers' needs. There is an experimental, native PHP module for > it, but we still allow them to execute imagemagick as a shell command. > Luckily, nobody didn't find out yet that these programs run as > www-data (apache) and are NOT limited by safe_mode. imagemagick has a > function which can read out textfiles and output them as image .. uh, > get the idea? MySQL-passwords, sourcecodes .. an evil customer could > just sweep our whole database. > > Currently security only consists in not letting our customers know > about these issues. We are working on a solution with the CGI version > and PHPWrap, which is a patched CGIWrap (something like suEXEC). Until > then, we just have to pray. > > it's unbelievable, but there are even admins who have safe_mode turned > off: > > http://www.altavista.com/sites/search/web?q=phpinfo+safe_mode+Off&kl=XX > > the last big company I saw doing that was mchost.com (~1000 customers > on one box). Terrible company. I was shocked about how STUPID admins > could be. I wrote them a mail and the answer was like "..uuuh safe_mode.. > never heard of that ..". GREAT. > > mod_php != virtual hosting > > Kind Regards, > Daniel Lorch > http://daniel.lorch.cc/ > -- > @echo "Hello, World"; > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
