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]
