My provider is in the process of trying to migrate everyone to new (supposedly more secure) servers. We use shared hosting, and something else is not an option due to cost considerations for the non-profit organizations involved. There have been several severe impacts of this migration on my XOOPS installations. I have a workaround for one of the problems, but I still have two others that need resolution and I'd like other opinions please. I'll need to look for another provider if I can't find some satisfactory workaround.
Problem #1 (with workaround) -
The provider uses symlinks (or possibly mounts) to manage the physical path for the site's files.
This keeps debug_backtrace() from giving the same path as the path installed in XOOPS_ROOT_PATH. When mainfile.php has this checking turned on (which it is by default) the failed compare results in the message :
"XOOPS path check: Script is not inside XOOPS_ROOT_PATH and cannot run."
I've written the following workaround in mainfile.php to get the site minimally running, but since safe_mode is removed for PHP 6, I'm wondering if this attempt at protection is really too ineffective to bother using at all. What is the real value of this check, and is there any other way to do it?
if ( XOOPS_CHECK_PATH && !@ini_get('safe_mode') ) {
// -DJD- workaround for symlink issues with debug_backtrace()
/* --------------------------------------------------------
if ( function_exists('debug_backtrace') ) {
$xoopsScriptPath = debug_backtrace();
if ( !count($xoopsScriptPath) ) {
die("XOOPS path check: this file cannot be requested directly");
}
$xoopsScriptPath = $xoopsScriptPath[0]['file'];
} else {
$xoopsScriptPath = isset($_SERVER['PATH_TRANSLATED']) ? $_SERVER['PATH_TRANSLATED'] : $_SERVER['SCRIPT_FILENAME'];
}
-------------------------------------------------------- */
if ( function_exists('debug_backtrace') ) {
if ( !count(debug_backtrace()) ) {
die("XOOPS path check: this file cannot be requested directly");
}
}
$xoopsScriptPath = isset($_SERVER['PATH_TRANSLATED']) ? $_SERVER['PATH_TRANSLATED'] :
$_SERVER['SCRIPT_FILENAME'];
// -DJD- workaround
if ( DIRECTORY_SEPARATOR != '/' ) {
// IIS6 may double the chars
$xoopsScriptPath = str_replace( strpos( $xoopsScriptPath, '\\', 2 ) ? '\\' : DIRECTORY_SEPARATOR, '/', $xoopsScriptPath);
}
if ( strcasecmp( substr($xoopsScriptPath, 0, strlen(XOOPS_ROOT_PATH)), str_replace( DIRECTORY_SEPARATOR, '/', XOOPS_ROOT_PATH)) ) {
exit("XOOPS path check: Script is not inside XOOPS_ROOT_PATH and cannot run.");
}
}
Problem #2 (annoying, but not a show-stopper) -
Xoops creates file names for /cache and /templates_c that FTP clients such as FireZilla and WS-FTPPro are unable to delete from the new server.
Level 2 support at my provider tells me that the legacy platform uses a GRSEC infrastructure whereas the new platform uses LDAP, and that the file names contain characters that are illegal on the new servers. I know what LDAP is, but I'm not a UNIX geek and I can't understand why this would cause the FTP client to get a "550-Forbidden command argument" when trying to delete the file. The provider's web-based File Manager, logged in using the same FTP id/pwd, can successfully delete the files, but it is extremely difficult and time consuming to use.
Can anyone shed some light on what is happening here?
Problem #3 (a potential show-stopper) -
For security reasons, the provider will no longer permit any directories outside of the public_html tree to execute scripts.
This impacts the Protector module, and I'm wondering if there is any point in installing this module if the XOOPS_TRUST_PATH must be inside public_html. Doesn't that defeat one of its primary purposes?
Thanks for any comments or insights you may have.
