register_globals=on for suexec/suphp ?

meeti

Well-Known Member
Dec 25, 2007
119
0
66
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.
 

darren.nolan

Well-Known Member
Oct 4, 2007
257
0
66
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.
Code:
global_registers on
Easy as.
 

craigedmonds

Well-Known Member
Oct 29, 2007
114
0
66
Europe
cPanel Access Level
Root Administrator
Twitter
suexec + register_globals + localised pnp.ini file = disaster

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

cPanel Development
Staff member
Apr 7, 2006
4,607
79
458
cPanel Access Level
Root Administrator
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.
 

Stefaans

Well-Known Member
Mar 5, 2002
461
4
318
Vancouver, Canada
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.
Code:
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.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,042
230
368
cPanel Access Level
Root Administrator
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).
 
Last edited:

dragon2611

Well-Known Member
Nov 30, 2003
124
0
166
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

Well-Known Member
Aug 10, 2002
2,042
230
368
cPanel Access Level
Root Administrator
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.
 

cPanelKenneth

cPanel Development
Staff member
Apr 7, 2006
4,607
79
458
cPanel Access Level
Root Administrator
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.
 

cPanelKenneth

cPanel Development
Staff member
Apr 7, 2006
4,607
79
458
cPanel Access Level
Root Administrator
Not if group or other have read-only access ;)
Code:
[email protected] [/home34y69da/tramel]# touch deleteme
[email protected] [/home34y69da/tramel]# ls -l deleteme
-rw-r--r--  1 root root 0 Apr 24 11:32 deleteme
[email protected] [/home34y69da/tramel]# su - tramel
[email protected] [~]# rm deleteme
rm: remove write-protected regular empty file `deleteme'? y
[email protected] [~]# ls -l deleteme
/bin/ls: deleteme: No such file or directory
[email protected] [~]#
 

sparek-3

Well-Known Member
Aug 10, 2002
2,042
230
368
cPanel Access Level
Root Administrator
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.
This is true. Though I've never run into a problem with this. It may be better to store this folder somewhere out of the user's home directory.

Not if group or other have read-only access ;)
The user would be able to delete the root owned file if it is in a directory that is owned by the user itself. This is because the deleting action is actually being done at the parent level. If you take my example of:

/home/user/php/php.ini

If you break it down /home/user/php/php.ini is owned by root /home/user/php is owned by root /home/user is owned by user.

The user cannot delete the actual php.ini file in /home/user/php, nor can they write changes to it (assuming that permissions on the file are 644 or less). However, the user can delete the directory /home/user/php. Now all the user has to do is recreate the /home/user/php path and now /home/user/php is owned by user allowing user to create a /home/user/php/php.ini file.
 

bornonline

Well-Known Member
Nov 19, 2004
139
0
166
Earth
Can't they just override it with the same flag in .htaccess? If so, all this worthless. I'll test when I get some time, but was hoping someone may have already checked this...guess not so far.

Thanks
 
Last edited:

sparek-3

Well-Known Member
Aug 10, 2002
2,042
230
368
cPanel Access Level
Root Administrator
I'm not sure of the cPanel version of suPHP, but I run a customized suPHP system and I patch the code so that it does not allow suPHP_ConfigPath in .htaccess files.