From a security standpoint it is better to use either of them, however you will find that not everything (especially PHP applications) is compatible with sUExec. Plus it is very easy for a user to break his own web site by changing the permissions on a file/directory. Plus, if you will be wanting to use Apache 2.x in the future, PHPSuExec is not available (to my knowledge) for Apache 2.x, then you would need suPHP, which is very similar.
depends pretty much on the purpose of the box.
if using phpsuexec on a box with 1 website and slammed with a ton of visits, it will simply shoot your load through the roof, i am talking here about sites with more than 400 000 page views per day.
on the other hand if hosting a few websites , and need protection, phpsuexec will help a lot, in tracking.
hope helps
if using phpsuexec on a box with 1 website and slammed with a ton of visits, it will simply shoot your load through the roof, i am talking here about sites with more than 400 000 page views per day.
on the other hand if hosting a few websites , and need protection, phpsuexec will help a lot, in tracking.
hope helps
SuExec is an absolute must no matter what!
Now with that out of the way, let's talk about PHP ...
Personally, I do not recommend phpSuExec because it cause more security problems
than it solves and it's advantages are limited because you can track usage of scripts
with more advanced logging (easy to setup) and don't really need PHP scripts to
be executed as the user ID if your concern is tracking script usage.
If your concern is that of users on the same server accessing each others files then
that is an area where you might consider phpSuExec but I would still lean away from it
for both performance and security reasons.
Now, if your are using Apache 2.x or 2.2.x then I will take the exact opposite argument
and recommend you go with SuPHP which provides the same functionality as phpSuExec
but doesn't have any of the additional security problems that phpSuExec brings!
I highly recommend using both, from the beginning.
Again, I'd be interested in hearing what security problems phpsuexec supposedly creates.
The only problem I'm aware of is that if you have a heavily - and I mean HEAVILY - loaded webserver, you should probably not run it. Having said that, the sort of load we're talking about here is extreme and the wins for most shared servers via running phpsuexec far exceed any minimal performance penalties.
Regardless of whether you use phpsuexec or not, permissions on a website are relatively easy to break!! In either case, you need to provide access to "nobody" - ie mode 751, or am I missing something?
This is completely untrue, in my experience. PHPsuexec prevents generic access to other people's information (ie passwords in PHP scripts), it makes it easily possible to limit and track spammers, and it makes exploit processes easily identifiable. That sounds like a win to me. Specifically what security problems did you think phpsuexec brought?
Suphp is also a great idea, although I have no experience with it. It's a pity cpanel don't integrate it into their Apache 1.3 installation as well.
Again, I'd be interested in hearing what security problems phpsuexec supposedly creates.
The only problem I'm aware of is that if you have a heavily - and I mean HEAVILY - loaded webserver, you should probably not run it. Having said that, the sort of load we're talking about here is extreme and the wins for most shared servers via running phpsuexec far exceed any minimal performance penalties.
Regardless of whether you use phpsuexec or not, permissions on a website are relatively easy to break!! In either case, you need to provide access to "nobody" - ie mode 751, or am I missing something?
Suexec
According to Apache HTTP Server Version 1.3, Suexec: "provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server."
For detailed information about Suexec, go to: http://httpd.apache.org/docs/1.3/suexec.html
PhpSuexec
Php, without PhpSuexec, runs as an Apache Module, executes as the user/group of a web server, in this case "nobody".
When PhpSuExec is enabled (running as CGI with suexec enabled) your Php scripts execute under your UID/GID level and not nobody/nobody. Files or directories that you require your Php scripts to write to no longer need to have 777 permissions. In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them. Your scripts and directories can have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else). That said, PhpSuExec is much more secure than Php running as a Apache module.
- The Downside to, or the impact of, using Phpsuexec:
(Adapted from http://forums.deftechgroup.com/showthread.php?t=574)
According to Apache HTTP Server Version 1.3, Suexec: "provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server."
For detailed information about Suexec, go to: http://httpd.apache.org/docs/1.3/suexec.html
PhpSuexec
Php, without PhpSuexec, runs as an Apache Module, executes as the user/group of a web server, in this case "nobody".
When PhpSuExec is enabled (running as CGI with suexec enabled) your Php scripts execute under your UID/GID level and not nobody/nobody. Files or directories that you require your Php scripts to write to no longer need to have 777 permissions. In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them. Your scripts and directories can have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else). That said, PhpSuExec is much more secure than Php running as a Apache module.
- The Downside to, or the impact of, using Phpsuexec:
- Performance:
Since Php is running via a CGI interpreter which adds a little overhead to your CPU.
- Php Scripts:
Some scripts do not like the Phpsuexec CGI environment as it changes certain Php internal system variables causing them to fail.
- .htaccess:
Manipulating some Php settings is not possible (use a local Php.ini instead)
- Security:
Files / Directory permissions given a world read+write+execute 777 will not work, instead these files will need to be changed to 755
- Php eAccelerator:
ZendOptimizer works, however other popular Accelerators such as eAccelerator won't.
- URLs:
Variables in URL not encoded as regular variables that is variables inside the URL path, not expressed like view.Php?=view will not work.
(Adapted from http://forums.deftechgroup.com/showthread.php?t=574)
Last edited: