register_globals=on for suexec/suphp ?

[meeti]

Hi,

the register_globals of my server wide is set as "off",

and the server runs as suexec/suphp,

how can i set as "on" for certain account?


thanks a lot.

[cpanelkenneth]

Add it to an httpd.conf Include for the account.

[meeti]

Add it to an httpd.conf Include for the account.

Hi,

can you tell me more detail?

Server API CGI

thanks

[darren.nolan]

You could create a php.ini in their folder (needs to be in EACH folder that PHP is required to be run with global registers on) - and place the following line.

global_registers on

Easy as.

[craigedmonds]

You could create a php.ini in their folder (needs to be in EACH folder that PHP is required to be run with global registers on) - and place the following line.

I have tried this and it does not work.

We are running Apache Version: 1.3.41 and SuExec with register_globals set to Off.

Since installing SuExec the other day, on one of our sites we get the following error:

"Server Requirement Error: register_globals is disabled in your PHP configuration. This can be enabled in your php.ini configuration file or in the .htaccess file in your catalog directory"

Then accoring to every web page about this error, we then put an php.ini file containing the following line:

register_globals = ON

Still get the same error.

According to my server guy he is saying

"In older phpsuexec installations, you can use local php.ini files to override variables locally. However, ever since cpanel11's latest easyapache installer, this does not work with phpsuexec any more. You can test this by putting a phpinfo page and a php.ini in the same directory and you'll see that it does not read the local php.ini. You can also contact cpanel and ask them if you want to verify. This function does not work with phpsuexec anymore as of the latest installer."

Is what he is saying correct and if so how do we work around it?

We cant be the only web server in the world that has this problem.

[cpanelkenneth]

I have tried this and it does not work.

We are running Apache Version: 1.3.41 and SuExec with register_globals set to Off.

Since installing SuExec the other day, on one of our sites we get the following error:

"Server Requirement Error: register_globals is disabled in your PHP configuration. This can be enabled in your php.ini configuration file or in the .htaccess file in your catalog directory"

Then accoring to every web page about this error, we then put an php.ini file containing the following line:

register_globals = ON

Still get the same error.

According to my server guy he is saying

"In older phpsuexec installations, you can use local php.ini files to override variables locally. However, ever since cpanel11's latest easyapache installer, this does not work with phpsuexec any more. You can test this by putting a phpinfo page and a php.ini in the same directory and you'll see that it does not read the local php.ini. You can also contact cpanel and ask them if you want to verify. This function does not work with phpsuexec anymore as of the latest installer."

Is what he is saying correct and if so how do we work around it?

We cant be the only web server in the world that has this problem.

First: phpsuExec no longer exists. There is only suExec support and mod_suphp support (for the pedantic: phpsuExec refers to some special patching we used to perform to suExec, patching we no longer do as it was far too problematic).

Second: when using suExec only, you will need to either make the modification to the server wide php.ini file (usually in /usr/local/lib/php.ini) or add the overrides directly to the VirtualHost needing the override, using the php_ directives (see the PHP manual for more information on this).

Third: if using mod_suphp, then your can provide a php.ini in the local directory of the user and it will be used.

[craigedmonds]

Thanks for that info.

I have passed it on and hopefully things can get worked out.

[Stefaans]

You could create a php.ini in their folder (needs to be in EACH folder that PHP is required to be run with global registers on) - and place the following line.

global_registers on

Easy as.

There is a danger in doing it exactly as you explain. When you have a php.ini in the user directory, it is not a case that it overrides only the specified directives of your main (server-wide) php.ini. In fact, your main php.ini is not considered at all. This means that having only one or more directives in the local php.ini, all other directives revert to their default settings, which may be insecure or bad for performance.

My advice would be to put a comprehensive php.ini in the user directory that includes settings for all important directives that affect security. For example, copy your main php.ini (which should have all the security and performance tweaks you want) to the user directory, and then make the selected changes to the user's php.ini.

[Branko]

Also have you considered using register global emulation in one global configuration.php file as shown on: http://www.php.net/manual/en/faq.mis...egisterglobals

[sparek-3]

If you are using suphp the easiest solution is to add this line in the VirtualHost container for that Virtualhost:

suPHP_ConfigPath /home/user/php

Then create a /etc/phpconf/user directory and copy your server-wide php.ini file to that directory. Edit the /etc/phpconf/user/php/php.ini and enable register_globals. Then restart Apache.

If you are using Apache2 or EA3, you will want to use the include system so you will want to create a folder:

mkdir -p /usr/local/apache/conf/userdata/std/2/user/domain.com

Then create a suphp.conf file in that directory (/usr/local/apache/conf/userdata/std/2/user/domain.com/suphp.conf).

Add the lines:

<IfModule mod_suphp.c>
suPHP_ConfigPath /etc/phpconf/user
</IfModule>

Run /scripts/ensure_vhost_includes --user=user

This will cause suphp to read the php.ini file that is in /home/user/php instead of the server-wide php.ini file.

Of course, the absolute best action is to figure out why the script needs register_globals in the first place. Is the script the latest version? Do the developers realize that register_globals is going to be deprecated in PHP6? Any script that requires register_globals in order to work really falls into one of two categories. Either the project that created the script is dead and the script is no longer being maintained (therefore a security risk). Or the script was developed by someone who is not an expert PHP programmer and how much trust do you really want to put in such a PHP script? (They may be a beginner PHP programmer, and beginners do make mistakes there's nothing wrong with that, but they need to be educated about their mistakes).

[dragon2611]

If you are using suphp the easiest solution is to add this line in the VirtualHost container for that Virtualhost:

suPHP_ConfigPath /home/user/php

Then create a /home/user/php directory and copy your server-wide php.ini file to that directory. Edit the /home/user/php/php.ini and enable register_globals. Then restart Apache.

If you are using Apache2 or EA3, you will want to use the include system so you will want to create a folder:

mkdir -p /usr/local/apache/conf/userdata/std/2/user/domain.com

Then create a suphp.conf file in that directory (/usr/local/apache/conf/userdata/std/2/user/domain.com/suphp.conf).

Add the lines:

<IfModule mod_suphp.c>
suPHP_ConfigPath /home/user/php
</IfModule>

Run /scripts/ensure_vhost_includes --user=user

This will cause suphp to read the php.ini file that is in /home/user/php instead of the server-wide php.ini file.

Of course, the absolute best action is to figure out why the script needs register_globals in the first place. Is the script the latest version? Do the developers realize that register_globals is going to be deprecated in PHP6? Any script that requires register_globals in order to work really falls into one of two categories. Either the project that created the script is dead and the script is no longer being maintained (therefore a security risk). Or the script was developed by someone who is not an expert PHP programmer and how much trust do you really want to put in such a PHP script? (They may be a beginner PHP programmer, and beginners do make mistakes there's nothing wrong with that, but they need to be educated about their mistakes).

Personally id put the custom PHP file for that account somewhere the user can't actually get to it and preferably with permissions that mean they cant change it.

Doesn't have to be in their home directory I'd argue its safer that its not.

[sparek-3]

Personally id put the custom PHP file for that account somewhere the user can't actually get to it and preferably with permissions that mean they cant change it.

Doesn't have to be in their home directory I'd argue its safer that its not.

I agree. I would do all of these steps as root. Then the user will not be able to make changes to the php.ini file (it will be owned by root) but Apache will still be able to read it. Putting it under the user's home directory allows for it to be backed up as part of the cPanel backup and just gives it good structure.

But, you may be right, creating an /etc/suphpconfs directory (or some such directory) and creating a directory structure under that directory might be even more secure.

[bornonline]

Can a user override suPHP_ConfigPath /home/user/php with another path in .htaccess unless you remove "Options" from the Apache AllowOverride setting?

Can any one confirm that has already tested?

Would this kill mod_rewrite?

[cpanelkenneth]

A root owned file in a a user owned directory can be deleted by the user. Then the user simply needs to create his own php.ini in its place.

[Stefaans]

A root owned file in a a user owned directory can be deleted by the user.

Not if group or other have read-only access