The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

register_globals On

Discussion in 'General Discussion' started by rip_curl, Mar 1, 2006.

  1. rip_curl

    rip_curl Well-Known Member

    Joined:
    Jan 30, 2005
    Messages:
    81
    Likes Received:
    0
    Trophy Points:
    6
    Hello
    how can I make register_globals On for individual user? I don't want to switch it on on server.
     
  2. kernow

    kernow Well-Known Member

    Joined:
    Jul 23, 2004
    Messages:
    865
    Likes Received:
    9
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Go to the directory where your clients php scripts are. Then create a new file called php.ini
    Then edit that file and put this line in it:
    register_globals = On
     
  3. AndyReed

    AndyReed Well-Known Member
    PartnerNOC

    Joined:
    May 29, 2004
    Messages:
    2,222
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Minneapolis, MN
    For security purposes, some people might disagree with me, but if I were you, I wouldn't switch register_globals ON. I'll keep them OFF.

    To learn more about register_globals, to share your thoughts and read others comments, go to: http://us3.php.net/register_globals
     
  4. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    I'd agree with Andy here - for security reasons, it is strongly advisable to keep register_globals off, even if a client wants it turned on.

    If the answer is to turn register_globals on, you're asking the wrong questions. To be more specific, alternative solutions exist and one that reduces security should not be considered.
     
  5. Radio_Head

    Radio_Head Well-Known Member

    Joined:
    Feb 15, 2002
    Messages:
    2,051
    Likes Received:
    1
    Trophy Points:
    38
    Anyone knows which are the security problems of register_globals on when safe_mode is on ?

    In each case I don't think very useful to turn off register_globals off because it can be set to on using .htaccess .

    (the good point is that php 6 has deprecated register_globals on from source code ,
    so with php6 register_globals will be definitely off)
     
  6. jackie46

    jackie46 BANNED

    Joined:
    Jul 25, 2005
    Messages:
    537
    Likes Received:
    0
    Trophy Points:
    0
    You may agree with Andy Reed but that depends on your user needs, whether you have phpsuexec installed or if your running Fantastico in which case haveing register globals OFF is not an option. Mediocure hosts that do nothing but host .html pages can get by with this setting being OFF. Competative hosts such as what we have would find users screaming and moving elsewhere to get what they want in order to be able to run their applications. In our case, this is not an option to have it OFF.

    Pats on the back to Andy Reed. I completely disagree with his suggestion. Of course it makes the box more secure and there is no denying that, but thats beside the point. We want to make our users happy and there are other avenues to follow in making sure that your box is not compromised.
     
    #6 jackie46, May 13, 2006
    Last edited: May 13, 2006
  7. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    Only because users don't understand or don't care about the security issues related to having register_globals on. And if you think that turning register_globals on just because a user insists then you don't understand the issues either.

    register_globals really does nothing much more than allow $_POST['postvar'] and $_GET['getvar'] to be accessed directly as $postvar and $getvar without having to first declare or define them. This is something that can easily be worked around or simulated.

    register_globals never needs to be on. Simply replacing all instances of $postvar with $_POST['postvar'] and $getvar with $_GET['getvar'] would sort things out.

    If this is really too much of a problem, the following code will register_globalify $_POST and $_GET:

    Code:
    foreach($_POST AS $key => $value) { ${$key} = $value; }
    foreach($_GET AS $key => $value) { ${$key} = $value; }
    Furthermore, register_globals will no longer be an option as of PHP6. Rather than panic over it when the time arises, it's just better to phase it out now.

    On a more positive note (after re-reading my post it might seem a little harsh, which is not my intent), if a user insists on having register_globals turned on, explain the security-based reasons why this is not an option and put forward alternatives for working around the problem or simulating the behaviour of register_globals. If you have to, be blunt and point out that they can have security and reliability or a given script and ask them what they consider to be more important.

    I also try my best, when possible, to find patches and/or newer versions of scripts that are no longer dependent on register_globals. A patch exists for oscommerce, for example. Users that insist that register_globals is turned on are, admittedly, not happy that I won't allow it however the fact that I will do as much as possible to make things work with register_globals turned off seems to alleviate any unhappiness.

    I would also find it hard to trust in the abilities of a PHP developer if they insisted that either their script must have register_globals on to function or insist that it is impossible to change the script so that it is no longer dependent on register_globals. It's not that tricky and any competent developer would have no problems.
     
  8. AndyReed

    AndyReed Well-Known Member
    PartnerNOC

    Joined:
    May 29, 2004
    Messages:
    2,222
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Minneapolis, MN
    Very well said, webignition. ;)
     
  9. apodigm

    apodigm Well-Known Member

    Joined:
    May 12, 2003
    Messages:
    67
    Likes Received:
    0
    Trophy Points:
    6
    This is nice discussion. I understand the philosophy debate and the declarations from PHP about register_globals.

    Regardless, I would still like an answer to the original question. :) I have a single customer who has an application that will be time consuming to upgrade. While the patches are installed, I would like to "buy some time" by allowing register globals on only that one single account - without allowing them on the server-wide php.ini.

    I'm running php 4.3.3 and php 5.1.4 with phpsuexec. I've noticed the php_flag arguments in .htaccess do not work. And I've tried putting the php.ini file in the hosting directory and that also does not work. php_admin_flag in the httpd.conf configuration for the virtual host also does not work.

    Can someone explain what I am missing or how to implement register_globals on a single account in the phpsuexec environment?
     
  10. nat

    nat Well-Known Member

    Joined:
    Jan 16, 2003
    Messages:
    204
    Likes Received:
    0
    Trophy Points:
    16
    Just upgraded to PHP Version 5.1.4 with phpsuexec and placing register_globals = On in a php.ini file is no longer turning it on.

    A phpinfo file in the same directory as the php.ini file still shows it off for both the local value and master value.

    Can some with 5.1.4 phpsuexec try it for a second to see if it works or if i'm nuts.
     
  11. Mysteerie

    Mysteerie Well-Known Member

    Joined:
    Dec 29, 2003
    Messages:
    129
    Likes Received:
    0
    Trophy Points:
    16
    Yes, I have the same problem.
     
  12. Secret Agent

    Secret Agent Guest

    Same here, how do we use register globals on in htaccess when phpsuexec support is enabled?
     
  13. XPerties

    XPerties Well-Known Member

    Joined:
    Apr 10, 2003
    Messages:
    401
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    New Jersey, USA
    Same issue here. Anyone have a fix or work around?
     
  14. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    I still think that enabling register_globals just to get a script working is about as sensible as replacing the wheels on your car with large round cheeses just to get your sound system to work.

    Surely if people chose not to use large round cheeses on their axles, companies would soon stop developing sound systems dependent on such large round cheeses.
     
  15. XPerties

    XPerties Well-Known Member

    Joined:
    Apr 10, 2003
    Messages:
    401
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    New Jersey, USA
    Since you seem to be full of wisdom (and humor if I might add) could you enlighten me with your vocal point when dealing with multiple clients regarding their scripts and not working?


    :D
     
  16. nat

    nat Well-Known Member

    Joined:
    Jan 16, 2003
    Messages:
    204
    Likes Received:
    0
    Trophy Points:
    16
    It's hard when there are thousands of clients that used fantastico to install scripts. These people don't know php coding, they didn't create the code, they cannot modify the code, and cannot afford to hire a coder to fix the script. I'm unable to go through thousands of scripts trying to fix code I didn't create. Being not that good with php doesn't help either. Many of these people seem to rather just find a host that has it turned on than trying to get the code fixed. cancellations galore

    The authors of many of these scripts, like oscommerce, still require it to be on. (there is a 3rd party hack for oscomemrce, but i think that isn't officially supported by the developers of oscommerce)

    I heard php is going to stop supporting register_globals alltogether starting with php 6. I hope that this is modivating the authors of popular scripts to start changing their code.

    If you have a lot of client's using register_globals on, I don't think there is a way to do it right now without causing many problems for many clients.
     
  17. XPerties

    XPerties Well-Known Member

    Joined:
    Apr 10, 2003
    Messages:
    401
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    New Jersey, USA

    All good and valid points which I agree with but right now turning it globally off and trying to allow clients to enable it in their php.ini file doesn't work so it would be much helpful from anyone who has found a resolution.
     
  18. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    The OSCommerce patch is an official unofficial patch, if that makes sense. By that I mean that I mean it's not part of the OSCommerce distribution, but it is an official community contribution.

    http://www.oscommerce.com/community/contributions,2097
     
  19. webignition

    webignition Well-Known Member

    Joined:
    Jan 22, 2005
    Messages:
    1,880
    Likes Received:
    0
    Trophy Points:
    36
    True, dealing with Fantastico-installed register_globals-dependent scripts can be tricky. An upgrade of a script can easily wipe out any hard work undertaken to patch the problems.

    Personally, I'd prefer it if users cancelled and moved to a host that allows register_globals to be on. Eventually the hosts that do enable this setting will end up with plenty of users running scripts that are dependent on register_globals being turned on. The more scripts on the server that require register_globals to be on, the greater the chance of the server being exploited.

    When the number of hosts disabling register_globals hits a certain level, it will no longer make sense for script developers to create register_globals-dependent scripts. And when the density of register_globals-dependent scripts on register_globals-friendly hosts reaches a certain level, it will no longer make sense for serious users to choose such hosts. The situation should naturally resolve itself, with register_globals falling victim to evolution.

    The crucial problem is that people have a natural tendency towards greed, which will lead them to enable register_globals so as to secure those paying clients who think they need it. However the problems that an increase in the density of register_globals scripts on a given server present should eventually sort this out too as the exploit problems no longer makes register_globals financially sustainable.

    Rather than finding ways around getting register_globals enabled when it shouldn't be, it makes much much much more sense to simply disable it and deal as best you can with the cancellations that result. From a financial viewpoint, this is a much safer option compared to the level of dissatisfaction that will arise from users on frequently-exploited servers.

    If you disable register_globals, the worse case is that you'll have all register_globals users cancel at once. If you continue to enable register_globals, you are increasing the chance of the server being exploited, which then involves risking losing those other users who aren't dependent on register_globals, on top of losing all your register_globals-dependent users when you finally choose to disable the option due to the problems it causes you.

    It's only a matter of time, and don't let your desire to secure paying clients cloud your judgement. The chances of you having to disable register_globals increases over time such that I think it is fair to say that disabling it is inevitable. The fact that register_globals doesn't exist in PHP6 should be enough of a warning - it's basically saying that register_globals being enabled is such a problem that the PHP developers can't rely on hosts disabling it and have to force the situation.

    Rather than rushing into disabling register_globals when things go wrong, plan for this change, prepare for it and introduce the change in a controlled fashion and don't wait until you're forced into making the decision. Give weeks if not months of advance warning to your users whilst carefully explaining why the decision to disable register_globals was taken. This will also give you time to plan for how you will deal with the loss of users.
     
  20. lloyd_tennison

    lloyd_tennison Well-Known Member

    Joined:
    Mar 12, 2004
    Messages:
    698
    Likes Received:
    1
    Trophy Points:
    18
    Sorry, I missed where that code was being placed, - php.ini?


    Maybe that will do nothing as there are no instances of postvar or getvar in the offending scripts. They scripts will not work with it turned off, so there must be something else register_globals does too.
     
    #20 lloyd_tennison, Jul 23, 2006
    Last edited: Jul 23, 2006
Loading...

Share This Page