From: [EMAIL PROTECTED] Operating system: RedHat 7.0, current errata PHP version: 4.1.2 PHP Bug Type: Unknown/Other Function Bug description: open_basedir affects HTTP POST operations for provided form-handling scripts
I recently received a note from a customer regarding a problem getting one of the provided scripts working on a domain hosting server at work. I looked into that problem, and fixed it- but in the process noted that the form mail and guestbook scripts I had written for the server were no longer functional. Since the error message indicated some issue with the open_basedir option (set on a per-vhost basis via the Apache directive php_admin_value so as to not disrupt some internal services), I tried changing it for the test vhost set up on the system. The two ways I could get the two scripts working were: 1) Remove the open_basedir restriction. This is how the system was set up initially, but was soon restricted for security reasons. This is not a practical long-term solution. 2) Move the scripts (the real filesystem location!) to a subdirectory of the directory containing all vhosts. This is what I have active now, in order to keep 40-odd websites functioning. I tried using a symlink in the test domain's webroot, but that failed as well. I can understand this affecting include()/fopen() and similar "direct" access to files; I don't understand why this affects HTTP POST operations. -- Edit bug report at http://bugs.php.net/?id=17548&edit=1 -- Fixed in CVS: http://bugs.php.net/fix.php?id=17548&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=17548&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17548&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17548&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17548&r=support Expected behavior: http://bugs.php.net/fix.php?id=17548&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17548&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17548&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=17548&r=globals
