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.

phpsuexec - explained

Discussion in 'General Discussion' started by pfmartin, Aug 5, 2003.

  1. pfmartin

    pfmartin Well-Known Member

    Joined:
    Aug 18, 2001
    Messages:
    167
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Earth
    I thought I would write down my notes on phpsuexec so that it is understoon by others. I know that I had a hard time understanding how it was supposed to work. So here goes:

    First off, for security, we want to run PHP with suEXEC. Why? Because that way scripts are executed under the username of the domain owner. Making it easier to track what they are doing and emails that are sent. It also limits what they can modify and whether they can view session data in the /tmp folder. OK, you should know the benefits of suEXEC... so I won't dig any deeper.

    The first thing you need to realize is that for PHP to use suEXEC, it must be run as a CGI. This is probably the most secure way of running PHP. This is in contrast to running it as a module (i.e. mod_php).

    The problem with running php as a CGI is that it would require all PHP scripts to start with an opening spec (just like most UNIX scripts) saying what the interpreter to use is. For example, you would have to change ALL your PHP scripts to have the following first line:
    Code:
    #!/usr/bin/php
    
    Now, this is a problem because you would then need to change ALL php scripts to have this first line. Of course, this would be out of the question if you had many sites or worse, many servers... Your clients would be upset and it would take a while to implement.

    That's where phpsuexec comes in. It is nothing more than a module loaded into Apache that essentially prepends that line to PHP scripts so that you don't need to go and edit all of them. THIS IS THE MAGIC!

    This that I explained so far was the piece of the puzzle that I needed in my mind to understand it best.

    Now, knowing how it worked, I went back and made sure that I had taken these steps to get it working:

    1. Make sure you compile PHP as a binary. (In my case, I build my own PHP and not the one with easyapache).
    2. Make sure you place the PHP binary into /usr/bin (it must be here since this is where the phpsuexec patch will look for it).
    3. Recompile easyapache. In my case, I specify to use phpsuexec and also tell it to NOT compile PHP since I use my own.
    4. The easyapache script comments out the php module loading from httpd.conf. This is normal because, of course, you are no longer using PHP as a module.
    5. Once apache restarts it starts running PHP scripts with the binary PHP.

    Now the fun starts. Because PHP is a binary now, and being suEXEC'd, the same rules apply as they do when you suEXEC any other script. That is, the script must abide by the following rules:

    1. User executing the wrapper must be a valid user on this system.
    2. The command that the request wishes to execute must not contain a /.
    3. The command being executed must reside under the user's web document root..
    4. The current working directory must be a directory.
    5. The current working directory must not be writable by group or other.
    6. The command being executed cannot be a symbolic link.
    7. The command being executed cannot be writable by group or other.
    8. The command being executed cannot be a setuid or setgid program.
    9. The target UID and GID must be a valid user and group on this system.
    10. The target UID and GID to execute as, must match the UID and GID of the directory.
    11. The target execution UID and GID must not be the privledged ID 0.
    12. Group access list is set to NOGROUP and the command is executed.

    Once you convert over to phpsuexec, you should probably babysit the suexec_log file (/etc/httpd/logs/suexec_log) to check for any errors. WHM has the nify "Fax script permissions" thingy that will automatically change perms for you so that they are correct.

    The other issue you have to deal with are the php_value settings you probably have lying around on your server. php_value settings in .htaccess files are only interpreted by the module version of PHP. The binary version actually chokes on these and you get a Server 500 error.

    The way around this is to find all .htaccess files that have php_value in them. Then, copy php.ini into the same directory as the .htaccess file is located and apply the settings in .htaccess to php.ini. Then of course, remove the php_value settings from .htaccess and you are golden.



    I imagine I will run into more issues, but for now these are the main ones. I hope this helps others understand the phpsuexec beast. It's not that complicated once you understand it's purpose. Once again: It simply makes running PHP as a CGI easier to do by taking away the need to add the #!/usr/bin/php line to your scripts.

    Cheers.

    cPanel.net Support Ticket Number:

    cPanel.net Support Ticket Number:
     
    #1 pfmartin, Aug 5, 2003
    Last edited: Aug 5, 2003
  2. mpierre

    mpierre Well-Known Member

    Joined:
    Jun 30, 2002
    Messages:
    196
    Likes Received:
    0
    Trophy Points:
    16
    That sounds about right !

    I've been following the various PHPsuexec threads ( and posting in several of them ) since the beginning of the PHPSuexec integration in CPanel, and this is one of the best recaps...

    I'd have to review the rules, because if I remember well, a PHP can still be run if the directory is writable, as long as the PHP file itself isn't.

    But the rests seems ok.

    cPanel.net Support Ticket Number:
     
  3. Faldran

    Faldran Well-Known Member

    Joined:
    May 28, 2002
    Messages:
    136
    Likes Received:
    0
    Trophy Points:
    16
    One other small thing, is people setup a mime type, to run htm or html or other to run as php, you will have to make it an apache handler instead of a mime type.

    cPanel.net Support Ticket Number:
     
  4. MySundown

    MySundown Well-Known Member

    Joined:
    Jun 2, 2003
    Messages:
    128
    Likes Received:
    0
    Trophy Points:
    16
    phpsuexec still doesn't work with 4.3.2 though, right? I don't want to downgrade.

    I use easyapache btw, I'm not creating my own php build or anything like that.
     
    #4 MySundown, Aug 5, 2003
    Last edited: Aug 5, 2003
  5. mpierre

    mpierre Well-Known Member

    Joined:
    Jun 30, 2002
    Messages:
    196
    Likes Received:
    0
    Trophy Points:
    16
    Yes, it works with 4.3.2 now...

    I used it in 4.3.2 personally, and I built is with Easyapache.

    cPanel.net Support Ticket Number:
     
  6. MySundown

    MySundown Well-Known Member

    Joined:
    Jun 2, 2003
    Messages:
    128
    Likes Received:
    0
    Trophy Points:
    16
    OK, going to install it now. *crosses fingers*

    cPanel.net Support Ticket Number:
     
  7. rs-freddo

    rs-freddo Well-Known Member

    Joined:
    May 13, 2003
    Messages:
    832
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    Just a note:

    Any user can manipulate php.ini settings by uploading a plain text file called php.ini to a directory. For instance placing
    safe_mode = off
    in such a file turns safe mode off for that directory.

    If you, as sysadmin, want to control safe_mode, register_globals or any other php.ini setting then this is not for you. That said, if you don't want users to access system commands you probably shouldn't allow users a cgi-bin either.

    I also find with phpsuexec I no longer have to chmod files - i just upload with ftp.

    cPanel.net Support Ticket Number:
     
  8. MySundown

    MySundown Well-Known Member

    Joined:
    Jun 2, 2003
    Messages:
    128
    Likes Received:
    0
    Trophy Points:
    16
    It went well. No errors. :)

    cPanel.net Support Ticket Number:
     
  9. bmcpanel

    bmcpanel Well-Known Member

    Joined:
    Jun 1, 2002
    Messages:
    546
    Likes Received:
    0
    Trophy Points:
    16
    Does PHPSUEXEC (running php as cgi) hinder the performance of PHP compared to running it as a module?

    cPanel.net Support Ticket Number:
     
  10. anand

    anand Well-Known Member

    Joined:
    Nov 11, 2002
    Messages:
    1,435
    Likes Received:
    1
    Trophy Points:
    38
    Location:
    India
    cPanel Access Level:
    DataCenter Provider
    Yes this is a slight performance degradation.

    cPanel.net Support Ticket Number:
     
  11. Faldran

    Faldran Well-Known Member

    Joined:
    May 28, 2002
    Messages:
    136
    Likes Received:
    0
    Trophy Points:
    16
    I have personally never seen any performance changes since we have been using it. If it is, it is so slight, it does not register.

    cPanel.net Support Ticket Number:
     
  12. pfmartin

    pfmartin Well-Known Member

    Joined:
    Aug 18, 2001
    Messages:
    167
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Earth
    Performance

    Regarding Performance:

    From my perspective performance is better overall on Apache. This is because now each PHP page request is handled by a separate process. This leaves Apache without the obligation of processing things on it's own. So from the web visitor's perspective things seem more responsive.

    When using mod_php, you can basically bring the web server down to its knees by running a bad or evil script that sucks up Apache time. This would affect other users on the server.

    Using php as a binary you are still running the same number of overall processes, but Apache itself is not being hammered. At worst, you'd have a php process sucking up resouces. BUT... you would know which user was doing it because suEXEC makes sure you know :) So you'd have a chance to do something about it. With mod_php it's not so easy.

    I guess it boils down to this: if you are running a dedicated server for your own use, then mod_php is probably best. Might as well drive fast cause you're the only one on the road. For a shared environment ,PHP as CGI is 'better' from a safety perspective (there are other people on the road; slow down).

    As noted in a previous post, the performance issue is so small that it's not really noticeable.

    And in any case, I would rather drive slow and be safe, then drive fast blindfolded and without a seatbelt :)

    cPanel.net Support Ticket Number:
     
  13. pingo

    pingo Well-Known Member

    Joined:
    Nov 16, 2002
    Messages:
    430
    Likes Received:
    0
    Trophy Points:
    16
    Thanks alot for sharing :)

    John

    cPanel.net Support Ticket Number:
     
  14. rs-freddo

    rs-freddo Well-Known Member

    Joined:
    May 13, 2003
    Messages:
    832
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    Another advantage of phpsuexec is that mail without a "from" or "reply-to" header goes out with the correct "return-to" header, rather than as nobody. The php mail() function doesn't require "from" or 'reply-to" headers, so under the module it can go out as nobody.

    I guess in the end too. the only way to have a safe PERL installation will be to use some form of chrooted environment - phpsuexec will work with this too.

    Although mod_php allows tighter control of command line execution - cgi scripting in general needs to be tightened, and it's no good doing one without the other.

    cPanel.net Support Ticket Number:
     
  15. bmcpanel

    bmcpanel Well-Known Member

    Joined:
    Jun 1, 2002
    Messages:
    546
    Likes Received:
    0
    Trophy Points:
    16
    Thanks for the info. This is a good thread.

    cPanel.net Support Ticket Number:
     
  16. casey

    casey Well-Known Member

    Joined:
    Jan 17, 2003
    Messages:
    2,303
    Likes Received:
    0
    Trophy Points:
    36
    Location:
    If there is trouble, it will find me
    Some php scripts simpy don't work under phpsuexec, though, correct? In particular, I am concerned about ModernBill.

    cPanel.net Support Ticket Number:
     
  17. Dathorn_ADT

    Dathorn_ADT Active Member

    Joined:
    Nov 16, 2002
    Messages:
    41
    Likes Received:
    1
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator
    What about Zend Optimizer? So far phpsuexec seems to work great, but we haven't had any luck in getting Zend Optimizer to work with it and a fair amount of scripts require it.

    cPanel.net Support Ticket Number:
     
  18. Stefaans

    Stefaans Well-Known Member

    Joined:
    Mar 5, 2002
    Messages:
    451
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Vancouver, Canada
    Casey, we are running ModernBill and Phpsuexec just fine. No problems whatsoever.

    Dathorn_ADT, last time I installed Zend, it did not support the current version (at the time) of PHP. Selecting a previous version (I think it was 4.3.0) did the trick. I know it works because Moderbill's Zend encoded version is happy with the setup. ;)

    cPanel.net Support Ticket Number:
     
  19. sexy_guy

    sexy_guy Well-Known Member

    Joined:
    Mar 19, 2003
    Messages:
    848
    Likes Received:
    0
    Trophy Points:
    16
    Modernbill certainly does not work under phpsuexec. I could not get it to work.

    cPanel.net Support Ticket Number:
     
    #19 sexy_guy, Aug 7, 2003
    Last edited: Aug 7, 2003
  20. jamesbond

    jamesbond Well-Known Member

    Joined:
    Oct 9, 2002
    Messages:
    738
    Likes Received:
    1
    Trophy Points:
    18
    I haven't tried phpsuexec yet, but I'm willing to try it, just for the security improvement.

    I'm afraid of breaking scripts though.

    What about scripts using things like ImageMagick? Will these scripts break?

    cPanel.net Support Ticket Number:
     

Share This Page