Thanks Mamba.

You are right, it did not occur to me that my hosting company might block access to the directories installed outside the document root. It would be worth making a note of that in the installation docs.

What fooled me, in particular, is that some uninstalled modules, like catads, were visible. It might be worth thinking about why that is. It might suggest a fix. Also, the other site was actually on the same server but it is possible that I did not move those dirs outside of the root, as I intended that as a brief test installation. I can't look at that now, as I overwrote the files.

So, how big a security risk is it to keep the dirs inside the root. If a fix to 2.3.3 or the Protector module could be found, they could later be moved.

I assume that once I have my hosting company enable access outside the root, or move the dirs back inside, I can reload the protector folder and install it, changing mainfile.php and mainfile.dist.php appropriately?

I recognize that some modules, as installed, won't work under 2.3.3. That is one of the things I'm doing as I work on this. I am taking the opportunity to test modules, update them, and to change some of the features on the site. As 2.2.x was a dead end, I had not thought it worthwhile to update modules until I updated Xoops.

Anyway, thanks again and I'd appreciate it if you could post to this thread if and when a fix to this issue is found.

Regards,

Barry Cooper

Quote:
They were visible, because they were alphabetically before "Protector", so XOOPS loaded them just fine.

It seems like the Protector (or AltSys), breaks the loop to read all available modules, so whatever is after "Protector" won't get any chance to be visible. With AltSys it was a real problem for me, because there were no modules visible, since AltSys was the first one.

What would help if you could install XOOPS 2.0.18, and test in a similar configuration, i.e. few modules, version of Protector that requires XOOPS_TRUST_PATH, and then see if this has the same behavior, i.e. if the Protector cannot access XOOPS_TRUST_PATH, then if it breaks the loop and makes the modules after it invisible. This way we would know if AltSys and Protector are over-sensitive, or if XOOPS 2.3.x made them to behave this way.

Regarding security risk, it is highly recommended that you're able to have the XOOPS_TRUST_PATH outside of Document Root. So talk to your host and explain it to them.

What is the value for open_basedir in phpinfo()?

Mamba

I woke up early thinking about this. As a programmer I know just enough to be dangerous. What I don't understand about this is that XOOPS obviously can write to the directories outside of the root because the cache files get written to caches/smarty_compile. What is different about Protector wanting to access those dirs? It would be helpful to understand this better to be able to explain what I need to my hosting company.

I will try to run the test with XOOPS 2.9.18 before contacting the host.

Ghia

I ran phpinfo(). It returns "no value" for open_basedir. What should it be set to? I know I could set it in php.ini but my guess is that I can't set it to give access outside the root, as the php.ini file is inside. I'm assuming that this has to be set in httpd.conf

Mamba,

I have installed XOOPS 2.0.18 on the same server as my 2.3.3 site. I am ready to download Protector. I'm a little unclear what I should define XOOPS_TRUST_PATH as. In 2.3.3 it is define("XOOPS_TRUST_PATH", XOOPS_PATH); but 2.0.18 does not use the xoops_data and xoops_lib files located outside the root. Can you clarify this for me?

BC

For this exercise, you can can just define as:

define('XOOPS_TRUST_PATH','/home1/xxx/public_html/trust_path');

where you replace "xxx" with the name of your domain directory (for security, I won't use it here)

Of course, you need to define the "/trust_path" directory, and copy there files from the Protector.

So we're putting the trust_path dir INSIDE the root. Will that test the issue of being able to access files outside the root?

Well, it seems like this is actually not a problem with your host, but with the way you set it up in your mainfile.php, and I just overlooked it

You had originally something like this (some file/directory names have been changed for security):

define( 'XOOPS_PATH', '/home1/public_html/xoops_lib' );
define( 'XOOPS_VAR_PATH', '/home1/xxx/xoops_data' );

which is different.

Once I've changed

define( 'XOOPS_PATH', '/home1/public_html/xoops_lib' );

to

define( 'XOOPS_PATH', '/home1/xxx/xoops_lib' );

the Protector seems to work just fine, and all the not installed modules are visible as well.

Hmmm. I didn't see that either. It's odd because the XOOPS 2.3.3 upgrade checks those paths and they passed.

Well, at least the problem is solved and I can't thank you enough for your input.

Barry