hosted by liquidweb


Go Back   Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : php 5 handler dso vs cgi vs SuPHP
Reply

Forum Jump

php 5 handler dso vs cgi vs SuPHP

Reply Post New Thread In Hosting Security and Technology Subscription
 
Send news tip View All Posts Thread Tools Search this Thread Display Modes
  #1  
Old 03-19-2008, 01:00 PM
alex2007 alex2007 is offline
Newbie
 
Join Date: May 2007
Posts: 8
Question

php 5 handler dso vs cgi vs SuPHP


I wanted to ask an advice which php handler is the most secure to have on a shared server:

dso vs cgi vs SuPHP

I currently have dso with Suexec on and few accounts are getting phishing sites uploaded so I read that SuPHP is safer. What do you recommend?

If I do change the server to SuPHP should I enable Suexec as well in the whm: Configure Suexec and PHP?

Thank you for all your suggestions.



Sponsored Links
  #2  
Old 03-20-2008, 01:34 AM
SupaDucta SupaDucta is offline
Web Hosting Guru
 
Join Date: Jul 2004
Location: Reporting Live from Marrz
Posts: 254
SuPHP + CGI:

- somewhat slower output layer than DSO
- no PHP directives are allowed in .htaccess anymore, must be either in httpd.conf, main php.ini or per-vhost php.ini (the latter by using the suPHP_ConfigPath directive within vhost)
- more secure than DSO especially with Suhosin extension (Suhosin might require tweaking some of it's directives for some scripts)
- won't allow http://$IPADDRESS/~username invocations anymore if it's compiled in PARANOID mode, which is preferred and most secure way of running it
- since you are on cPanel, user 'nobody' can be disallowed to send mails to remote addresses in WHM

Keep in mind that you will need to check and potentially adjust the suphp.conf after install to keep it fully effective (to name just one as example, the default settings Minimum UID and Minimum GID can be set to whichever number cPanel started creating vhost users from (as you are on cPanel reading your post - 31000 or 32000 or something).

All in all suPHP is a very good and reliable piece of code, been using it myself whenever possible for quite a while.

All phishings and exploits won't just go away (some really large percentage will though), it is the exploitable and insecurely coded script that is crucial. What you use to host and protect, the other side uses to test, breach, learn and spread, so keeping those scripts updated, patched or replaced is also a very important component in this matter.

  #3  
Old 03-20-2008, 08:00 AM
sysfirm sysfirm is offline
Newbie
 
Join Date: Mar 2008
Location: US
Posts: 12
PHP can be run as CGI or as DSO (module). As a module, the PHP runtime is loaded once, when Apache starts up and then reused for all requests. As CGI, a new process is spawned on each request. Obviously DSO only works with Apache, so other servers need to use CGI. (Actually I'm not entirely sure about how true this is). Since DSO is only loaded once, it is quite a bit faster than CGI, but it has some limitations. First of all, you can't have multiple versions of the same module loaded at once, so you can't run two versions of PHP (say 4 and 5) both as modules. CGI doesn't have this limitation.

Another issue is that since the module is loaded inside Apache, the code is executed as the Apache user (Usually called www). This means that all sites on the same Apache server run under the same user. This is a huge security hazard on a shared host (Where different users are running as virtual hosts under the same Apache installation). PHP's safe_mode feature tries to remedy this on the PHP-runtime level, but it's a very patchy solution. Running PHP as CGI, you can assign different users for each host, which is the proper solution. I'm not sure, by I reckon that suexec is used for launching the CGI version as a different user than Apache, so it's part of the CGI solution, so to speak.

Another difference between CGI and DSO is that the DSO version has direct access to some Apache-specific calls, which gives you some more fine-grained control on the HTTP-level.

mod_security has no impact on the other settings, since it's a separate Apache module. It gets run before the PHP handler (CGI or DSO) is invoked. I haven't used mod_security, but I reckon that it's mostly useful for shared hosts.

Sponsored Links
  #4  
Old 03-21-2008, 06:57 AM
Xylitol Xylitol is offline
Junior Guru Wannabe
 
Join Date: May 2007
Posts: 79
Could someone quickly tell me the difference between php handlers suphp and cgi?

  #5  
Old 03-21-2008, 01:00 PM
applicurearun applicurearun is offline
WHT Addict
 
Join Date: Mar 2008
Location: kolkata, India
Posts: 102
SAPI module that would somehow change the userid of the Apache
process handling the request to that of the owner of the php file. But it looks to be a hardwired setuid CGI wrapper

__________________
Sysfirm
So you think your server is secure?
Try our security Service
With SysFirm

  #6  
Old 01-08-2011, 11:23 PM
moonslice moonslice is offline
New Member
 
Join Date: May 2001
Posts: 2
It sounds like you are saying cgi is more secure than dso, but add that maybe it uses suexec.

However we cannot use suexec on one server because of a particular app. (Also suphp won't work with a different app).

So in that case, which would be more secure as a php 5 handler - cgi or dso?

Thanks!

  #7  
Old 01-09-2011, 05:03 AM
funkywizard funkywizard is offline
unghhh... Baaandwidth....
 
Join Date: Jan 2005
Posts: 9,012
It's really hard to say which is best. suexec / cgi will run PHP as the user who owns the php file. This has the disadvantage that the php script will have all the same permissions as that user, to delete or modify any files owned by that user. In a DSO setup, all the php files are run by "nobody" so only world writable files can be edited by your php scripts. On the other hand, with suexec you can restrict php from reading files owned by other users, and with DSO you're not able to do that. So it's a trade off. Neither is totally secure, they have advantages and disadvantages to each other.

If you want to talk about performance instead of just security, then FCGI will use a lot less ram under apache than DSO will. In DSO, a copy of php is loaded into each apache client slot. With FCGI, the apache client slots will stay much smaller, and you only have to load as many copies of php as the number of php scripts you're running at any given time. So when you're loading images and things in apache, the apache client handling that image request isn't wasting several megs of ram also having a copy of php built in.

So FCGI is a good choice for saving ram although the security implications of having php run as an actual user instead of nobody means that your system needs to be secure from malicious users uploading their own php files or exploiting the php files already on the server.

__________________
IOFLOOD.com -- We Love Servers
Need More IPs? Up to 253 IPs per server.
Email (sales [at] ioflood . com) for details.

  #8  
Old 01-30-2011, 03:06 AM
boomshadow boomshadow is offline
Newbie
 
Join Date: Jan 2011
Location: USA
Posts: 15
DSO vs. CGI vs. suPHP vs. FastCGI

Choosing the right PHP handler for your site is critical. Unfortunately, handlers are often the least understood.

I researched the different PHP handlers pretty extensively and tested them on large number of servers. I was able to compile together a great description guide with the results.

It has helped a large number of customers at the web hosting company I work for. I hope it'll help you guy out as well:

DSO vs. CGI vs. suPHP vs. FastCGI << BoomShadow.net

  #9  
Old 01-30-2011, 05:04 AM
funkywizard funkywizard is offline
unghhh... Baaandwidth....
 
Join Date: Jan 2005
Posts: 9,012
Quote:
Originally Posted by boomshadow View Post
Choosing the right PHP handler for your site is critical. Unfortunately, handlers are often the least understood.

I researched the different PHP handlers pretty extensively and tested them on large number of servers. I was able to compile together a great description guide with the results.

It has helped a large number of customers at the web hosting company I work for. I hope it'll help you guy out as well:

DSO vs. CGI vs. suPHP vs. FastCGI << BoomShadow.net
I'm going to have to disagree with a couple of your main points here:

1) FCGI uses more memory than CGI or DSO: Wrong

DSO uses more memory than FCGI or CGI because DSO puts a copy of PHP into every apache client slot. Serving up a static file? Yeah, that's going to have a copy of php compiled in.

FCGI only loads up php for as many copies are required to service your php requests, leaving your apache slots much leaner. The overall memory savings here can be immense, and it will be basically the same as with CGI as well. The tiny bit of memory you save by not immediately killing a copy of php as you would in cgi is almost nothing, and more than offset by the massive cpu savings in not recycling a copy of php for every request.

2) FCGI / CGI suPHP is more secure than DSO: Not necessarily

Running scripts as "nobody" is generally more secure than running scripts as the owner of the file, because "nobody" doesn't have arbitrary write permissions to modify files owned by the user. under FCGI / CGI suPHP, where you run as the user, there's nothing you can do to stop a buggy / insecure php script from modifying important files, or editing the webpages owned by that particular user. In a non-shared hosting environment, FCGI / CGI suPHP opens up a really bad security hole with no particular security benefit.

In a shared hosting environment, there is a tradeoff, that DSO is less secure insofar as one user's scripts reading / messing with another user's files, whereas FCGI / CGI suPHP makes it easier for an external attacker to mess with one particular user's files. Which tradeoff you want to pick is up to you, there's no right answer there. But for a single-user environment, DSO is demonstrably more secure.

__________________
IOFLOOD.com -- We Love Servers
Need More IPs? Up to 253 IPs per server.
Email (sales [at] ioflood . com) for details.

  #10  
Old 01-30-2011, 06:27 AM
boomshadow boomshadow is offline
Newbie
 
Join Date: Jan 2011
Location: USA
Posts: 15
Quote:
Originally Posted by funkywizard View Post
I'm going to have to disagree with a couple of your main points here:

1) FCGI uses more memory than CGI or DSO: Wrong

DSO uses more memory than FCGI or CGI because DSO puts a copy of PHP into every apache client slot. Serving up a static file? Yeah, that's going to have a copy of php compiled in.

FCGI only loads up php for as many copies are required to service your php requests, leaving your apache slots much leaner. The overall memory savings here can be immense, and it will be basically the same as with CGI as well. The tiny bit of memory you save by not immediately killing a copy of php as you would in cgi is almost nothing, and more than offset by the massive cpu savings in not recycling a copy of php for every request.

2) FCGI / CGI suPHP is more secure than DSO: Not necessarily

Running scripts as "nobody" is generally more secure than running scripts as the owner of the file, because "nobody" doesn't have arbitrary write permissions to modify files owned by the user. under FCGI / CGI suPHP, where you run as the user, there's nothing you can do to stop a buggy / insecure php script from modifying important files, or editing the webpages owned by that particular user. In a non-shared hosting environment, FCGI / CGI suPHP opens up a really bad security hole with no particular security benefit.

In a shared hosting environment, there is a tradeoff, that DSO is less secure insofar as one user's scripts reading / messing with another user's files, whereas FCGI / CGI suPHP makes it easier for an external attacker to mess with one particular user's files. Which tradeoff you want to pick is up to you, there's no right answer there. But for a single-user environment, DSO is demonstrably more secure.

My tests have shown otherwise. FastCGI has persistent connections that it leaves open. I often seen where Apache needs to be restarted just to close them all out. This causes a high memory issue.

The security question you raise is true. It can be argued which is more secure. suPHP and FastCGI will allow a script to have write access to the rest of your account files, letting it corrupt the rest of them. However, the damage is limited to just that one account. It cannot write to any other accounts or system files.

I personally feel that restoring/cleaning just one account is far easier.

DSO has the capability that a hacker could compromise more than just the account files, they could get to your system files. Although they are limited in how many they can get, and they typically only go after certain ones, I personally do not want any possibility of anything other than user files getting corrupted.

Reply

Related posts from TheWhir.com
Title Type Date Posted
Servers on Demand: Custom Water-Cooled Servers in One Hour Web Hosting News 2013-09-16 14:53:25
RagingWire Earns Energy Star Certification for Second Sacramento Data Center Web Hosting News 2013-02-08 12:11:28
PayPal UK IPN Issues Impact Web Hosts, Users Web Hosting News 2013-02-01 09:34:43


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes
Postbit Selector

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump
Login:
Log in with your username and password
Username:
Password:



Forgot Password?
Advertisement:
Web Hosting News:



 

X

Welcome to WebHostingTalk.com

Create your username to jump into the discussion!

WebHostingTalk.com is the largest, most influentual web hosting community on the Internet. Join us by filling in the form below.


(4 digit year)

Already a member?