Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

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.

SuPHP and shared code

Discussion in 'General Discussion' started by larryl, Aug 8, 2008.

  1. larryl

    larryl Active Member

    Joined:
    Feb 19, 2007
    Messages:
    42
    Likes Received:
    0
    Trophy Points:
    156
    We have successfully upgraded to apache2/php5/suphp and stamped out all of the little flare-ups. The last thing I need to work out is how to give access to several shared packages we offer to our customers.

    Using apache1/php4/phpsuexec these were installed to /usr/local/share, chmod'ed to root:wheel, and configured to look for very small local files in each site user's home directory. Aliases in httpd.conf pointed users to the shared software using their own URL's. SuPHP is very unhappy with this arrangement - the UID's are above the minimum, not owned by the site users, etc, etc. Is there a viable way to get SuPHP to execute this shared code without gutting the very nice security features it implements? Short of that, can I get Apache to invoke php some non-SuPHP way only when calls to these specific aliases are made from the virtual sites but use SuPHP for all other php requests?
     
    #1 larryl, Aug 8, 2008
  2. djbob2

    djbob2 Well-Known Member

    Joined:
    May 14, 2005
    Messages:
    100
    Likes Received:
    0
    Trophy Points:
    166
    Unfortunately, I had this same problem a while back and found no solution. There is no way of configuring suPHP to ignore specific files, directories, users, etc.

    A few options you have here:
    1) Add this site software to the cPanel skeleton directory so that it is created once for every new account. That might take a substantial amount of disk space though, but it would be contained within your users' quotas and they could delete the apps if they didn't need them.
    2) Install these programs within cPanel. That way these could use cPanel's internal PHP, which is a different build and does not use suPHP.
    3) Install both PHP 5 and PHP 4 through Easyapache, and use one through suPHP and the other through CGI/FCGI/DSO. This can be configured about the build by going to Service Configuration -> Configure PHP and Suexec. On newer versions of WHM this page pops up in an AJAX pop-up after a successful build anyways.
    4) Manually install two copies of PHP 5.

    If your internal scripts can work with PHP 4, I recommend option #3. Perhaps option #1 if your apps are small and don't need root privileges.
     
    #2 djbob2, Aug 8, 2008
    Last edited: Aug 8, 2008
  3. larryl

    larryl Active Member

    Joined:
    Feb 19, 2007
    Messages:
    42
    Likes Received:
    0
    Trophy Points:
    156
    Thanks for the thoughts. I don't want to install in every site, as upgrades would be ugly and the code would be duplicated everywhere, as you mentioned.

    The third and fourth options have promise and were along the lines I was thinking of. Implementation would be the trick - getting apache to use a different method of invoking php when it redirects a user to one of those specific aliases. All of the code will work with php5.
     
    #3 larryl, Aug 8, 2008
  4. djbob2

    djbob2 Well-Known Member

    Joined:
    May 14, 2005
    Messages:
    100
    Likes Received:
    0
    Trophy Points:
    166
    Does the code work with PHP4? You'll probably just need to configure one extension (ie. .php) for one install, and another extension (ie. .php4) for another install. Then, disable execution path (don't remember if this is in httpd.conf or php.ini) for all but the required path on yourself "unsafe" installation.
     
    #4 djbob2, Aug 8, 2008
  5. jdlightsey

    jdlightsey Perl Developer III
    Staff Member

    Joined:
    Mar 6, 2007
    Messages:
    126
    Likes Received:
    2
    Trophy Points:
    168
    Location:
    Houston Texas
    cPanel Access Level:
    Root Administrator
    Does it allow you to execute the scripts if you disable the paranoid_uid_check and paranoid_gid_check in /opt/suphp/etc/suphp.conf? You might also need to adjust the min_uid and min_gid values if the shared scripts are owned by a system user like nobody or root.

    There was a somewhat related issue that came up before about shared scripts that are symlinked into the docroot of a vhost where the symlink owner and the target script owner don't match. Mod_suphp checks for this and throws a security exception regardless of the paranoid_uid_check and paranoid_gid_check settings, but from the way you describe your configuration it doesn't sound like you would encounter this problem.
     
    #5 jdlightsey, Aug 8, 2008
  6. larryl

    larryl Active Member

    Joined:
    Feb 19, 2007
    Messages:
    42
    Likes Received:
    0
    Trophy Points:
    156
    Installing php4 concurrently has some merit. All of the code will run under either php4 or php5. I might do a manual second install of php5 to run with dso just for those directories, then try to figure out how to get cPanel to keep the necessary httpd.conf modifications through its next round of updates.

    I tried removing the paranoid checks and lowering the min UID. That led me to the error that the directory was not owned by the user, which is the site user under SuPHP. I'm sure I could disable that as well, but I really don't want to disable all the security. It would just be nice to exclude it from directories that I have created and explicitly approve.
     
    #6 larryl, Aug 8, 2008
  7. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    846
    Likes Received:
    3
    Trophy Points:
    168
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    The problem with installing php4 is that it's end of life is past. There won't be any more support for php4 in terms of security updates from php, and who knows how long cPanel will support it.
     
    #7 verdon, Aug 8, 2008
  8. djbob2

    djbob2 Well-Known Member

    Joined:
    May 14, 2005
    Messages:
    100
    Likes Received:
    0
    Trophy Points:
    166
    suPHP stills makes sure that the target file UID is the same as the runner's UID, as the same for GID. I'm relatively sure there's no way to disable that check. Doing so would pretty much render suPHP useless though. The thing that suPHP really needs to put in as a feature is the ability to tell it allow certain files, users, and groups without checking them.

    The good thing about this situation, though, is that if you know what scripts are being run you can make sure they are secure. PHP 4 seems okay for this situation.
     
    #8 djbob2, Aug 9, 2008
(You must log in or sign up to post here.)
Loading...
Similar Threads - SuPHP shared code
  1. Krydos

    Ea-php72 doesn't update suphp.conf

    Krydos, Sep 18, 2017, in forum: EasyApache
    Replies:
    1
    Views:
    64
    cPanelMichael
    Sep 19, 2017
  2. Sametto Chan

    suPHP vs FastCGI PHP Handler

    Sametto Chan, Sep 9, 2017, in forum: Workarounds and Optimization
    Replies:
    7
    Views:
    120
    Sametto Chan
    Sep 13, 2017
  3. filip212

    suPHP vs CGI with PHP-FPM

    filip212, Aug 27, 2017, in forum: EasyApache
    Replies:
    10
    Views:
    217
    cPanelMichael
    Aug 31, 2017
  4. vlee

    suPHP broke websites

    vlee, Jul 20, 2017, in forum: EasyApache
    Replies:
    4
    Views:
    204
    vlee
    Jul 20, 2017
  5. PeteS

    Jail Apache vs suPHP

    PeteS, Jun 26, 2017, in forum: Security
    Replies:
    3
    Views:
    209
    cPanelMichael
    Jul 10, 2017

Share This Page