Apache comes bundled with its own security wrapper application called suEXEC. SuExec is a security mechanism for wrapping dynamic content (SSI & CGI) – content displayed based on user input and scripts executed. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server. suEXEC allows users to run CGI and SSI programs as the owner of the site as opposed to the owner of the httpd process ( usually “nobody” ).
Here’s how suEXEC works. When a request is made for a CGI or SSI file not owned by “nobody”, the request is passed to suEXEC along with the program name and the owner’s user/group ID. suEXEC then runs a series of checks to ensure the request is valid. If it is, the script is executed. If the request fails any of the checks, the script is not run and an error is logged.
The suexec wrapper isn’t turned on or off by any particular Apache directive setting. Instead, when the Apache server is compiled, one of the constants set (SUEXEC_BIN) is a string pointing to the location of the suexec binary. When the server starts, it looks for the binary at that location; if it’s found, suexec is enabled — otherwise it isn’t.
Installing and Compiling apache with suexec
Download your apache source from http://www.apache.org/
[bash]
wget http://apache.downlod.in/httpd/apache_1.3.37.tar.gz
[/bash]
Unpack it
[bash]
tar -zxf apache_1.3.37.tar.gz
[/bash]
Configure apache with your favourite options. The options enable, caller=nobody, docroot=/usr/local concerns with suexec.
[bash]
cd apache_1.3.37
./configure –enable-module=most –with-layout=Apache –prefix=/usr/local/apache
–with-port=80 –enable-suexec –suexec-caller=nobody –suexec-docroot=/usr/local
[/bash]
If you want to change the location of the suexec binary, you can do so by adding a new definition of SUEXEC_BIN to the compilation flags:
[bash]
env CFLAGS=”-Wall -DSUEXEC_BIN=\”/usr/local/apache/suexec\”” \
> ./configure –enable-suexec …
[/bash]
Checking your suEXEC setup
Before you compile and install the suEXEC wrapper you can check the configuration with the –layout option.
Example output:
[bash]
suEXEC setup:
suexec binary: /usr/local/apache/sbin/suexec
document root: /usr/local/apache/share/htdocs
userdir suffix: public_html
logfile: /usr/local/apache/var/log/suexec_log
safe path: /usr/local/bin:/usr/bin:/bin
caller ID: www
minimum user ID: 100
minimum group ID: 100
[/bash]
When configuration is all done, Install it
[bash]
make
make install
[/bash]
Disabling suexec
If your Apache installation is currently suexec-enabled, it’s very simple to turn the wrapper off. Just do one or more of the following to the suexec binary:
*Clear the setuid bit
*Change the owner to be someone other than root
*Delete or rename it
and then restart the Apache server. Doing any one of these will render the suexec facility unusable, and Apache won’t even try to involve it. To verify that your action has had the desired effect, verify (if you’re running Apache 1.3.11 or later) with the “/usr/local/web/apache/bin/httpd -l” command. If the output says suexec is enabled, you haven’t done enough yet.
Since the point of suexec is to handle certain Web requests under a different identity than the Apache server user, there needs to be some way to specify just which user. There are two places from which Apache will draw this information:
*The username from URLs such as http://somehost.com/~username/foo.cgi
OR
*The User and Group directives in the server configuration file, httpd.conf
The username to use is determined by checking these in the above order.
Testing Your Installation
The simplest way to verify that suexec is functioning properly is to install a script that will tell you the username under which it’s being invoked.
Here is a sample script – test.cgi
[bash]
#!/bin/sh
echo “Content-type: text/plain”
echo “”
echo “Username=”\`whoami\`
[/bash]
To test that suexec will properly handle a CGI script in a user’s directory, copy your test.cgi script into that user’s public_html/ directory, make sure that both the script and the public_html/ directory itself are mode 755 and owned by the user, and then request the script with a URL such as . If you get an error page, look at the Apache and suexec logs.
Debugging
Debugging a suexec problem can be frustrating, particularly since almost any problem with a CGI script in a suexec-enabled environment turns out to be related to the wrapper.
The typical warning signal of a suexec problem is a request for a CGI script that results in a ‘500 Internal Server Error’ page. The real error message will be found in your suexec log – /usr/local/apache/logs/suexec_log ( which may vary according to the configuration you used)
Best of Luck !! 🙂
