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 Step-by-Step Guide?

Discussion in 'General Discussion' started by MattFulger, Jan 27, 2006.

  1. MattFulger

    MattFulger Member

    Joined:
    Dec 4, 2005
    Messages:
    7
    Likes Received:
    0
    Trophy Points:
    1
    Hey all,

    I've recently had phpsuexec installed and configured on our
    server and we've run into a few problems with php scripts no
    longer working. Which mostly had to do with either file/folder
    permissions set incorrectly (because you can no longer use 777
    which unfortunately, TONS of php script install instructions advise
    users to use 777. :( ) or because of .htaccess files being used
    to parse other files extentions as php or use any other php
    functions available when running php as an apache_mod.

    Now, I've been doing a TON of research on these issues and just
    running PHPSuExec in general. From what I get out of all the reading
    I've done so far, is that phpsuexec helps tighten security, tracks
    scripts, logs activity and forces scripts to run as user instead of nobody.
    All of this sounds great and has actually helped us track down a
    spam attack our server recently underwent.

    However, it also seems that when you already have tons of php
    scripts installed which were running under php as an apache mod,
    you are almost certainly gonna run into a boat load of issues that
    will seem to break many of your php scripts. :(

    Again, much of this will have to do with file/folder permissions and/or
    .htaccess settings for your php scripts. The problem I'm having is that
    everywhere I go to read about how to fix these problems tell you that
    you will need to comment out .htaccess settings and/or delete the .htaccess
    files AND recreate those settings in a php.ini file within EACH directory
    you are running php scripts (that have .htaccess files). I also read that
    this is actually better for clients and webhosts both in that the server will
    be more secure and the client actually has more control over their accounts
    and what they can do with php.ini files.

    Ok. I'm game. ;)

    But just exactly HOW do we recreate/convert .htaccess files to php.ini files
    instead? I mean, I know to create the files in any text editor and all
    that jazz. But is there a concise guide as to what to look for in .htaccess files
    that will need to be changed and HOW to actually convert those settings
    to code that will actually work in a php.ini file, which will do the same
    thing the previous .htaccess was doing?

    I've even searched for info on php.ini directives and values, but this
    just led to more confusion as nothing I found fully explained what
    they actually do. At least, not in a way that I can understand it. All I've
    been able to find is cryptic info that assumes you already know what you
    are doing. lol

    So if anyone could point me to some more detailed PHPSuExec info
    and how to convert/recreate .htaccess to php.ini files, it would be
    greatly appreciated!

    Thanks in Advance!

    Peace & Prosperity,
    Matt Fulger
     
  2. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    Just a few quick comments that come to mind -

    You shouldn't find many .htaccess files with php directives in them. It shouldn't be too hard to run a grep for them - something like:

    Code:
    find /home -name .htaccess | xargs grep -i php_ /dev/null
    Where I'm heading with this is that you could do the changes manually. It's only the php_ directives (php_value, php_admin, php_flag from memory) you'll need to change, and only a tiny handful of applications need them anyway. Other .htaccess directives will stay just as they are, so it's not as bad as it may sound at first. You'll be converting them into php.ini files instead.

    The main difference is that now PHP scripts, and other scripts assuming you have suexec as well, will run as the account user rather than the user "nobody". This means that nothing should need special write permissions (ie the typical "chmod 777" modes), and anything owned by nobody will need to be reset as in the next para and below.

    One change you'll have to make is to ensure that files and directories are owned by the user of the account rather than nobody. I'll leave that to you.

    Also, PHPsuexec will refuse to run writeable PHP scripts, and (I think) will refuse to run stuff in writeable directory paths. Files and directories that are writable to group or all should probably all have group/all write permission removed (they own the file so they can write it anyway) - something like this (test it carefully before using!!):
    Code:
    find /home -perm +022 | xargs chmod go-w
    Watch the PHPsuexec/suexec log file for errors, it will help you a lot.

    Overall, I suspect you won't find it as bad as you think. Please post here to let us know how you go.
     
    #2 brianoz, Jan 30, 2006
    Last edited: Jan 30, 2006
  3. MattFulger

    MattFulger Member

    Joined:
    Dec 4, 2005
    Messages:
    7
    Likes Received:
    0
    Trophy Points:
    1
    PHPsuexec, .htaccess and php.ini....

    Brian,

    Thanks a bunch for all the info. I think I'm starting to figure this
    stuff out. Although, I'm still a bit confused as to how to make
    the php.ini files to replace the .htaccess. However, fact is, we've
    found that most scripts are actually easier to install and work just
    fine without bothering with setting permissions at all.

    We had a ton of errors right off the bat. But we've managed to fix
    all of them that we've come across so far and it was mostly just
    permissions set to 777. We have run across a few issues with .htaccess
    files, but for the most part it was stuff that apparently wasn't really
    needed anyway & commenting certain lines out seems to have worked
    so far. There hasn't been anything too complicated yet. But I'm trying
    to get myself prepared in case we do get users who are having problems.

    Yes, we do have suexec as well, so we will be monitoring the logs as you
    mentioned and hopefully that will help us out tremendously. Logs usually
    do a good job of that. ;)

    At the moment we've actually run into an issue with an article directory script
    which uses an htaccess file and I'm trying to figure out what I need to do to
    fix it and make the script work. LOL

    The following code is what's in the file...

    Code:
    # -FrontPage-
      
    IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*
      
    <Limit GET POST> 
    order deny,allow 
    deny from all 
    allow from all 
    </Limit> 
    <Limit PUT DELETE> 
    order deny,allow 
    deny from all 
    </Limit> 
    
    php_flag session.use_trans_sid off
    
    RewriteEngine On 
    
    RewriteCond %{HTTP_HOST} . 
    RewriteCond %{HTTP_HOST}  !^www\. [NC] 
    RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1  [R,L]
      
    RewriteRule ^profile\/([^\/]+)/([0-9]+)     publicprofile.php?name=$1&id=$2     
    RewriteRule ^Category\/[^\/]+/([0-9]+)      index.php?catid=$1&mode=category    
    RewriteRule ^Article/[^\/]+/([0-9]+)/?(.*)  article.php?id=$1&act=$2            
    RewriteRule ^rss/[^\/]+/([0-9]+)            rssarticle.php?id=$1                
    RewriteRule ^myarticles/(.*)$               index.php?mode=myarticles 
    
    RewriteRule ^(.*)topauthorslist/	  topauthors.php?orderby=$1&ordertype=$2&namelike=$3&page=$4
    RewriteRule ^(.*)popularlist/	      populararticles.php?page=$2
    RewriteRule ^(.*)searchresult/	      indexser.php?page=$2
    
    From the information I've read and from your post, I'm guessing that this
    is waht's causing the problem: php_flag session.use_trans_sid off

    But I'm also wondering about all the spaces in the middle of most of the
    lines there. Is that normal? I haven't really had to mess about with htaccess
    to much other than for simple things like error handling, redirects and password
    protecting directories.

    Anyway, any advice would be greatly appreciated.

    Thanks in advance!

    Peace & Prosperity,
    Matt Fulger
     
  4. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    The spaces in the middle of the lines are fine, as far as I know. Remember, it stopped working after your change, so it's going to be the php_flag line. Comment out the php_flag line and move it into the php.ini file which should be in the same directory as the PHP code. (I think there is a difference there - .htaccess affects all directories below the directory with the .htaccess file, whereas the php.ini file only affects the current directory where the PHP code is executing).

    You'll need to check the PHP manual for the php.ini file syntax.

    Well done for taking this on and thanks for letting us know how you went. I think you'll find it makes the server a whole lot more supportable!
     
  5. MattFulger

    MattFulger Member

    Joined:
    Dec 4, 2005
    Messages:
    7
    Likes Received:
    0
    Trophy Points:
    1
    I'm persistant & got it all working now...:eek:)

    Hey Brian,

    It was a strain on my brain but I did get it working. This particular
    script was also trying to confuse me with such things as the IonCube Loader. :rolleyes:

    However, I already had it installed. For some reason, it didn't seem to be
    working at first even though I knew for a fact it was installed already. But
    I am familar with the IonCube loader as I had previously installed that along
    with the Zend Optimizer on a couple of other servers over the last couple
    of years because of the Modern Bill script. That script (MB) was much harder
    to make work than Zend or Ioncube. But I'm persistant and made it all work
    somehow. Of course, PHPSuExec broke it....or seemed to anyway. But that
    was several months after I had it installed and I was moving on to my own
    server by then. :D (I was simply helping a friend manage his servers before
    and geez, friends sure don't pay well...LOL)

    But I didn't mind cuz it was all a great learning experience and I basically
    got to fool around with root access on his server before moving on to my
    own. :cool:

    I'm starting to get the hang of all this stuff now, but I'm still in the learning
    process. Aren't we all? Anyhow, I'm getting sidetracked now.

    I was right and it was that php_flag session.use_trans_sid off line in the
    .htaccess file that was throwing everything off. Although, that didn't seem to
    fix the IonCube Loader issue. I'm not sure exactly what I did to make it work
    to be honest. I spent a couple hours looking for the correct php syntax, which
    was quite simple once I found it. It was simply session.use_trans_sid = 0.

    Man, do I ever love google. I also ended up adding the syntax for the IonCube
    within the domain php.ini file too since for some reason it wasn't being loaded
    even though it was already in the root server php.ini. But that was also simple:
    zend_extension = /usr/local/ioncube/ioncube_loader_lin_4.4.so

    I've also been smart enough to add comment tags in the php.ini so that if
    I ever manage to forget about this stuff in the future I can simply look in the
    php.ini file and find it next time. As I mentioned in my previous post, I've
    actually found that most scripts are easier to install now that we have phpsuexec
    enabled. And I'm fairly certain that it helps with the security of the server as
    well.

    Now, if I could just get spammers to leave my server alone, that would be
    great. Our server provider had already threatened to terminate our account
    over 2 spam complaints and it wasn't even coming from us or our clients.
    Damn hackers with their scripts and whatnot. Fortunately, we were able to
    track it down to specific user accounts and we were able to find the scripts
    that were being exploited.

    That alone is reason enough to keep PHPSuExec enabled in my opinion.
    If not for the logs, we could have been screwed.

    Anyway, I'm definately going to work through the minor issues and keep
    PHPSuExec and suexec both enabled. We aren't quite been confident enough
    to run FastCGI yet, but that could happen in the future too. ;)

    Ok, I've got to get back to work now.

    Thanks for the support!

    Peace & Prosperity,
    Matt Fulger
     
  6. openmixs

    openmixs Member

    Joined:
    Jan 22, 2006
    Messages:
    15
    Likes Received:
    0
    Trophy Points:
    1
    worth it ?

    after all of this
    i no its safer
    but is it worth it to install it ?
     
  7. jwiens

    jwiens Member

    Joined:
    Mar 8, 2004
    Messages:
    16
    Likes Received:
    0
    Trophy Points:
    1
    Absolutely. Not all migrations are that much work. I moved over a couple dozen domains on my host to a phpsuexec environment recently and only had problems with one or two consistant web-apps. Once I figured out the fixes to those, the setup was a breeze. Very few problems, and it's much, much nicer now knowing that my domains actually are separated securely.
     
  8. ZapX.net

    ZapX.net Well-Known Member

    Joined:
    Feb 24, 2005
    Messages:
    52
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Sidman, PA
    hi,

    Is anyone having trouble with enabling phpsuexec?

    In WHM -> software -> apache update, I check "PHP suEXEC Support", leave everythign else as it was,.and click the start build button. Everythign goes through fine, apache builds, php builds, but I get 500 errors all over the place.

    Scripts are chmod'd to 755, they are owned by their respective users.

    All I get from the error log is:

    "Failed to open log file. fopen: permission denied"
    and
    "premature end of script headers"

    In the suexec log, it looks like all is matching up fine, with the ownership of scripts. No errors there.

    I've tried with both php 5.1.2 and php4.4.2.

    One question though; if you're enabling phpsuexec, should the "Php Module (Version 4.3.3)" be checked? I have kept it checked

    I wanted to have php5 with phpsuexec and then install php4 as cgi, other way around would be fine too, but frankly, neither of those methods are working.

    OS is freebsd 5
    Apache is 1.3.34
    Tried both PHP5.1.2 and PHP4.4.2

    By the way, i've run:
    /scripts/chownpublichtmls
    /scripts/checksuexecpatch
    /scripts/fixsuexeccgiscripts
    hoping one of those would help. No such luck.

    Any help appreciated, greatly.

    Brandon
     
    #8 ZapX.net, Feb 8, 2006
    Last edited: Feb 8, 2006
  9. knkhan

    knkhan Registered

    Joined:
    Apr 20, 2006
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    phpsuexec same prob

    I am having similar problems to as Brandon had. and i have not found a solution yet. Brandon were u able to find the fix ?

    help needed.

    Khalid
     
  10. knkhan

    knkhan Registered

    Joined:
    Apr 20, 2006
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    phpsuexec problem

    well atlast i found the fix to my problem. it was not working just because i didnot have the following AddHandler line in my httpd.conf. so i added

    AddHandler application/x-httpd-php .php .php4 .php3


    Strange, that the easyapache scripts didn't add that line. It was too frustrating for me for 2 days to fix this. I hope it helps others.

    khalid
     
Loading...

Share This Page