PHP Settings

Status
Not open for further replies.
D

DD32

Guest
I've been having a great time trying to work out why i have NOT been able to get my custom php scripts to work on my subdomain... and i've finally found the culprit..

a non-default php setting which is EXTREMELY bad for security..
register_globals

So i went about disabling it on my account, of course, this can't be done via the main php.ini file as you guys have changed it.
PHP Manual says that the people who can change it are:
PHP_INI_PERDIR|PHP_INI_SYSTEM
Corresponing to:
PHP_INI_PERDIR Entry can be set in php.ini, .htaccess or httpd.conf
PHP_INI_SYSTEM Entry can be set in php.ini or httpd.conf

So i went about setting it in .htaccess.... only to find that setting this:
php_value register_globals off
OR
php_flag register_globals off

Breaks PHP.. Ie. i can only get 500 Internal Error with it..
i don't have access to httpd.conf either...
So is there another way to change this value for my specific account? Or would it be a value that would have to be changed system-wide?

So i trotted off to: http://www.php.net/manual/en/ini.core.php#ini.register-globals
http://www.php.net/manual/en/ini.core.php#ini.register-globals said:
register_globals boolean

Whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables.

As of PHP 4.2.0, this directive defaults to off.

Please read the security chapter on Using register_globals for related information.

Please note that register_globals cannot be set at runtime (ini_set()). Although, you can use .htaccess if your host allows it as described above. An example .htaccess entry: php_flag register_globals off.

Note: register_globals is affected by the variables_order directive.
Seems it's been set to off since 4.2 was released.. http://www.php.net/release_4_2_0.php

Unfortunatly i can't use ANY of the methods listed.. so, Any Help at all?
Anyway of using per-user php.ini files? ie /home/dd32/php.ini would be my php.ini file, and someone else could use /home/someone_else/php.ini - if they exist.. i know it's possible for per-user php.ini's so just a thought..

Oh and my account is dd32, subdomain is dd32.pcriot.com
Sorry ads currently arn't displayed as it's syncing with my home pc right now alot while i've been trying t figure out this problem, ads will be re-inserted As soon as i get a chance and stop overwriting the files.
 

Corey

I Break Things
Staff member
Messages
34,553
Reaction score
203
Points
63
I think it's a problem with PHPSuExec. I know the Internal Error 500 is caused from that. I believe you can use php.ini files individually, I'm not sure though on the extent you can make changes to global variables in them. Right now we can't shut off PHPSuExec so I don't know if there is currently anything we can do.

-Corey
 
D

DD32

Guest
Corey said:
I think it's a problem with PHPSuExec. I know the Internal Error 500 is caused from that. I believe you can use php.ini files individually, I'm not sure though on the extent you can make changes to global variables in them. Right now we can't shut off PHPSuExec so I don't know if there is currently anything we can do.

-Corey

Well as my post said, register_globals can be changed from either:
PHP_INI_PERDIR Entry can be set in php.ini, .htaccess or httpd.conf
PHP_INI_SYSTEM Entry can be set in php.ini or httpd.conf

So thats php.ini, httpd.conf, and .htaccess, only the last one would be accessable by us users..

Well looks like i've found a fix.
.htaccess files are useless with PHPsuExec, as the PHP isn't even running as Apache anymore, thus .htaccess is ignored..

By placing your own php.ini in your directory(which ever directory needs it) you cna effectivly override the value.
php_info now reports for me:
Configuration File (php.ini) Path /home/dd32/public_html/forum/php.ini

Looks alls well now...

-=DD32=-
 
D

DD32

Guest
uh guys...
With your upgrade of PHP from .10 to .11
you've disabled my fix for that simple problem.. it wasn't a huge security risk or anything allowing custom php.ini files, it only allows certain things to be changed.. and in this case, it was filling a huge security hole you had..

And it seems you also stuffed up, It's now not running as a CGI module, and is now ISAPI module...

That means that PHPsuExec Will no longer work.. uh yep :) i'm right:
Code:
nobody   19870  0.6  1.2 22488 12460 ?       SN   04:33   0:00 /usr/local/apache/bin/httpd
nobody   19881  0.0  0.0  2908  932 ?        RN   04:34   0:00 ps -aux
 
Status
Not open for further replies.
Top