PHP CGI compilation success and Security Questions

I'm the Unix-impaired guy attempting to compile PHP 3.0.5 as a cgi on my virtual host. Recently, I had the symptoms that the php binary worked from the command line, but would show a lot of garbage characters in the browser. It turns out that it was because I had --enable-discard-path=yes It may be related to the fact that the cgi is not in my web-tree and is being run with suExec. I'd like to help other folks in the future who encounter these symptoms by describing what went wrong and why. Alas, I'm still fuzzy on the details... It seemed to me that by discarding the path info, the cgi decided to use itself as the input file, since what I saw was a lot of garbage characters followed by some warnings from the PHP interpreter. In fact, it was the logic that it was losing the rest of the path info and eating itself by default that led me to guess that maybe that discard-path thingy was involved. Can you help me help others by giving me a better idea of what happened? I'll try and put in a Note or something if it gels enough for me to understand it. I've read and re-read the docs about --enable-discard-path and security, and all the words make sense individually, but I'm still not getting the point of it all. :-( There's a lot of terms/ideas in there that are old-hat to y'all, but are just vague notions to me. I'm not even 100% certain that having a cgi run by suExec from the cgi-bin directory with --enable-discard-path=no isn't a security risk. I just know it won't work for me at all with =yes. :-( Also, the ./setup script specifically says to use yes for --enable-discard-path when running as a cgi, so if nothing else, perhaps it should say "unless you are using suExec" so that dummies like me at least have a chance of guessing the right answer, or a clue about what to research to find the right answer. That's assuming that I'm correct that suExec is involved here. Or is it forced-redirect that has that message? THANKS!!! And I'm finally going to be able to convert all my servers to using a current PHP. Whooo Hoooo!!! :-) :-) :-) PS If this is all too general, here are some specific questions about the actual text of the docs, but you'll probably have to be looking at the docs to make sense of my questions: Would "suExec" be an example of a "CGI wrapper to create safe chroot and setuid environments for scripts"? Would it be worth mentioning suExec and/or some other examples? "CERT advisory CA-96.11 recommends against placing any interpreters into cgi-bin. Even if the PHP binary can be used as a standalone interpreter, PHP is designed to prevent the attacks this setup makes possible." The word 'if' in the second sentence is throwing me... Should it be 'though'? Or is it possible to somehow make PHP *NOT* be a standalone interpreter? What is even meant by standalone interpreter? I guess I'm just not sure that what I think this is saying is what it is saying. :-( And I'm not even into the technical stuff yet. "When invoked as a binary, PHP refuses to interpret the command line arguments." Does "as a binary" mean "from the command line" as opposed to "in response to a http request"? PHP does *something* with those arguments to get them into the $HTTP_GET_VARS, so what does "refuses to interpret" mean? So is this only to avoid attacks from other users with shell access? This part about "/secret/doc.html" and then "http://my.host.secret/script.php3" Is "doc.html" meant to be equivalent to "script.php3"? Why the switch? "if the request is given in this form" ==> it could be clearer by saying "this latter form". It also might help to say that "the web server checks the access restrictions of the cgi-bin/php binary, and simply passes on the path to the /secret/script.php3 file without checking /secret/script.php3 access restrictions". "If your server does not have any content that is not restricted..." Should that "not" in front of restricted be there? "...or the server does not have a way to communicate with the PHP binary that the request is a safely redirected request, you can specify the option --disable-force-cgi-redirect" Wait a minute. If my server can't tell PHP it's safe, *AND* I say --disable-force-cgi-redirect, then aren't both security measures being bypassed? "You still have to make sure your PHP scripts do not rely on one or another way of calling the script..." Huh? Oh, you mean that the script itself is not looking at PATH_INFO or somesuch and relying on the URL typed by the user to be in one of the two ways?... I guess I got that. After reading it 4 times. How about "You may need to rewrite existing scripts and carefully craft new scripts to avoid relying on the actual URL typed by the user." It would also help if you mentioned the specific functions/variables that are involved. "... is sometimes consider an insecure practice". Shouldn't that be "considerED"? "Therefore many sysadmins will prefer..." If I know I have the Action/Handler stuff correct, is it possible for somebody to scam the passwords from a script?... How can they get the source code? "Also if the method for making sure the requests are not redirected..." I thought the point was to make sure the requests *ARE* coming from a redirect and not a big long URL with the secret file included. Either I'm not getting this at all, or there's an extra "not" in here also... If it was just one, I would just go on with life, but it's so consistent, I'm wondering if I have the whole concept backwards... "When user_dir is unset, only thing controlling the opened file name is doc_root" =?=> "THE only thing controlling" So, the whole point of user_dir being unset is to make ~ not expand into the path the user's home directory? Is it only ~ that it affects or are there other things like ~? [It's really a lack of Unix knowledge here.] "user_dir and doc_root are independent" Well, okay, I guess... Why? When would you want one and not the other? "A very secure option is to put the PHP parser binary somewhere outside of the web tree of files." Is /cgi-bin/user/ considered part of the web tree of files? I'm really confused now. Does anybody actually put the binary in their /htdocs/user tree? Or does this mean outside of the /cgi-bin tree? I *REALLY* like PHP, and it has allowed me to build some pretty cool (I think) web sites very rapidly. Thanks again for a really great software package. It is much appreciated. -- "TANSTAAFL" Rich lynch@cognitivearts.com webmaster@ and www. all of: R&B/jazz/blues/rock - jademaze.com music industry org - chatmusic.com acoustic/funk/world-beat - astrakelly.com sculptures - olivierledoux.com my own nascent company - l-i-e.com cool coffeehouse - uncommonground.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net