Suexec and Apache: A Tutorial Page 3

If Apache does find the wrapper, it reports it in the server error
log like this:

[Thu Dec 30 01:24:43 1999] [notice] suEXEC mechanism enabled
(wrapper: /usr/local/web/apache/bin/suexec)

Up until Apache version 1.3.11, there was no way to be sure where a
compiled Apache server is going to be looking for the suexec
binary. As of 1.3.11, though, it’s part of the ‘compiled modules’ report
displayed by the ‘-l‘ switch:

    % /usr/local/web/apache/bin/httpd -l
    Compiled-in modules:
      http_core.c
      mod_so.c
    suexec: enabled; valid wrapper /usr/local/web/apache/bin/suexec
  

 The 'enabled; valid' notation means that the wrapper is

actually present in the indicated location, and the permissions are correct. If

the wrapper isn't there, or the permissions are wrong, the output will indicate

that suexec is disabled. 
Compiling Suexec

 Because most of suexec's control parameters are defined at

compile-time, the only way to change them is to recompile. And since the

wrapper works very closely with the Apache Web server--to the point of both

applications having to share some compile-time definitions--the way to

recompile suexec is to recompile all of Apache. If you've never

done this before, you can see a brief treatment of the process in the

"Building Apache at Lightspeed" section of this article. 

 There are several suexec-specific options to the

apache-1.3/configure script. Here they are: 

--enable-suexec
The presence of this option on the command line simply informs the

configure script that you want the wrapper to be built as well.

Without this option, suexec will not be built, even if there are

other suexec options on the command line. 

--suexec-caller=username
This mustbe the username under which your Apache server runs; that

is, the one specified on the User directive outside all

 containers. If suexec is invoked

by any other user, it assumes it’s some sort of probing attempt and fails to

execute (after logging the user mismatch). 

 The default username is

www. 

--suexec-docroot=path
This specifies the ancestor directory under which all CGI scripts need to

reside in order to be acceptable to suexec. (This restriction

doesn’t apply to scripts activated by ~username-style URLs.) If

you have multiple virtual hosts using suexec, their DocumentRoots

(if you’re using .cgi files) must all be located somewhere in the

hierarchy under this directory, or else the wrapper will assume someone is

trying to execute something unexpected and will log it as an intrusion attempt.

ScriptAliased directories must be under this hierarchy as well,

and this is in fact more important for them since they commonly aren’t

under the DocumentRoot.