Help - Search - Members - Calendar
Full Version: To suEXEC or not to suEXEC? That is the question.
The Planet Forums > Control Panels > cPanel/WHM
joLS
I am really confused here after reading through tons of posts about suEXEC.

Now, I am not referring to phpsuEXEC, but just suEXEC which many say is a MUST for good security, however, take a look at this quote from http://httpd.apache.org/docs/1.3/suexec.html

---------
Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.
---------

... and this one from the same site:

---------
Second, it is assumed you are familiar with some basic concepts of your computer's security and its administration. This involves an understanding of setuid/setgid operations and the various effects they may have on your system and its level of security.
---------

Also, check out this post:
http://forums.theplanet.com/lofiversion/in...php/t40851.html

...particularly this part:
---------
IT IS ABSOLUTELY CRITICAL THAT YOU DISABLE SUEXEC MODULE!

If you dont, people can simply execute files in /tmp as nobody, and create their own shell accounts on the box. neat huh?
---------

Okay, so here is my question:

If I go through WHM ---> Apache Update, and select all the usual modules per our needs but this time adding "suEXEC Module" WILL IT BE PROPERLY CONFIGURED?

Another quesiton; Will this break any scripts that are already installed on this production server?

Also, what exactly do I need to do regarding setuid/setgid? Should I change some config file somewhere on the server for setuid/setgid to tighten up security in this respect after enabling suEXEC?

Thanks for any input here :confused: :confused: :confused:

By the way, we are still at php 4.4.4. and I am getting into this whole thing wanting to upgrade to php 4.4.7

P.S. We are up to - WHM 10.8.0 cPanel 10.9.0-R10737
timdorr
I don't know what motivated the guy that wrote that post here on these forums, but he's completely incorrect. First off, SuExec doesn't affect PHP scripts when you have PHP compiled as an Apache module (which is what you get with EasyApache). With PHP set up that way, it runs within the Apache process, so it takes on whatever user that Apache uses By default, this is the "nobody" user. SuExec only affects CGI scripts, so it won't have any impact on PHP unless you run it as a CGI somehow (which is basically what PHPSuExec does).

Running a CGI script under a particular user account, rather than a generic global account like PHP has to be, is much more secure. You don't have to set file permissions to be globally readable, or writable if you want to allow your scripts to write to files. That means these CGI scripts can't traverse directories and read the content of other sites on your server as easily. Basically, you can use Linux file permissions how they were intended to be used.

So, you should always enable SuExec. It's just more secure in general.
joLS
Thanks much for your reply.

So I take it that this is the guy that is totally incorrect? ----> http://forums.theplanet.com/lofiversion/in...php/t40851.html

And I also take it that within the cPanel system the suEXEC wrapper will be properly configured these days? It appears that this was not always the case. See ---> http://marc.info/?l=bugtraq&m=108663003608211&w=2

Thoughts?

So will enabling suEXEC on a production server break scripts that are not set up exactly right, in much the same fashion that phpsuEXEC does?

Thanks again.

By the way, php v4.4.7 is fine, and we are about ready to put everything up to the lastest php v5.x anyway.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.