Home arrow Apache arrow Page 10 - Building Apache the Way You Want It

Building Apache with suExec support - Apache

Have you ever wanted to customize Apache? This article will help you get started on building a customized version of Apache to suit your own needs. It is taken from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006).

  1. Building Apache the Way You Want It
  2. Building Apache from Source
  3. General Options
  4. Enabling or Disabling Modules in Bulk
  5. Changing the Module Order (Apache 1.3)
  6. Building Apache from Source As an RPM (Apache 2)
  7. Advanced Configuration
  8. Determining Apacheís Locations Individually
  9. Choosing a MultiProcessing Module (Apache 2)
  10. Building Apache with suExec support
  11. Configuring Apache 2 for Cross-Platform Builds
  12. Configuring the Build Environment
  13. Building Modules with apxs
By: Apress Publishing
Rating: starstarstarstarstar / 14
August 18, 2005

print this article



suExec is a security wrapper for Unix systems that runs CGI scripts under a different user and group identity than the main server. It works by inserting itself between Apache and the external script and changing the user and group of the external process to a user and group configured for the server or virtual host. This allows you to have each virtual host run scripts under its privileges and thus partition them from each other. Before you build suExec, itís worth considering that Apache 2 provides a different solution to the same problem in the shape of the perchild multiprocessing module, which allows you to define a user and group identity per virtual host.

To get suExec support, you must tell Apache to use it at build time with the --enable-suexec option:

$ ./configure --enable-suexec

On its own, this is rare enough, however. For suExec to actually work, it also needs to have various configuration options set. None of these are configurable from Apacheís configuration to keep the suExec wrapper secure from tampering, so if you need to set them, you must define them at build time. Some of the defaults are also slightly odd and arenít governed by selecting an Apache layout, so if you use a different layout, youíll probably need to set some of them.

NOTE suExec is built so that it can only be run by the user and group of the main server as configured at build time. If you want to have suExec run by any User other than the default, then itís not enough to change the settings of the User and Group directives in the server-level configurationóthey must also be defined at build time so that suExec recognizes them.

Of particular note are the minimum values of the user and group ID and the document root. The user and group IDs are lower limits that are compared to Apacheís User and Group settings. They constrain the user and group under that suExec will allow itself to be run. This prevents the root user being configured, for example. If you want to use your own user and group with suExec, then you have to ensure that the correct settings are established up front; if you change them later to something below the allowed minimum values, then you must rebuild suExec or itíll detect that itís being run by the wrong user or group and refuse to cooperate.

The document root setting is slightly misnamed; it determines where suExec will permit executables to be run from. For a single Web site, it should be the document root, but for virtual hosts, it should be a parent directory thatís sufficiently broad enough to include all the virtual host document root directories somewhere beneath it. For example, if you have all your virtual hosts under /home/www/ virtualhostname, then the document root for suExec should be /home/www.

Table 3-6 lists all the configure options that control suExec.

Table 3-6. suExec Configure Script Options



[1.3] --server-uid=UID

Sets the user ID that Apache will run under, and that

[2.0] --with-server-uid=UID

suExec will allow execution by. The default is nobody.

[1.3] --server-gid=GID

Sets the group ID that Apache will run under and that

[2.0] --with--server-gid=GID

suExec will allow execution by. The default is nobody

under Apache 1.3 and #-1 under Apache 2.

[1.3] --suexec-caller=NAME

Sets the name of the user thatís allowed to call suExec.

[2.0] --with-suexec-caller=NAME

This should be set to the name of the User directive in

httpd.conf. The default is www.

[1.3] --suexec-docroot=DIR

Sets the root directory of documents governed by

[2.0] --with-suexec-docroot=DIR

suExec. This affects the user directory processing of

suExec. The default is PREFIX/htdocs.

[1.3] --suexec-logfile=FILE

Determines the location of suExecís log file. By default

[2.0] --with-suexec-logfile=FILE

this is the master server log directory.

[1.3] --suexec-userdir=DIR

Specifies the name of the subdirectory as inserted into

[2.0] --with-suexec-userdir=DIR

URLs by mod_userdir. If user directories are in use

and implemented by mod_userdir (as opposed to

mod_rewrite, say), suExec needs to know what the

substituted path is to operate correctly. The default is

public_html, which is also the default of the UserDir

directive in mod_userdir.

[1.3] --suexec-uidmin=UID

Specifies the minimum allowed value of the User

[2.0] --with-suexec-uidmin=UID

directive when evaluated as a numeric user ID. The

default is 100, restricting access to special accounts,

which are usually under 100 on Unix systems.

[1.3] --suexec-gidmin=UID

Specifies the minimum allowed value of the Group

[2.0] --with-suexec-gidmin=UID

directive when evaluated as a numeric group ID. The

default is 100, restricting access to special accounts,

which are usually under 100 on Unix systems.

[1.3] --suexec-safepath=PATH

Defines the value of the PATH environment variable

[2.0] --with-suexec-safepath=PATH

passed to CGI scripts. This should only include

directories that are guaranteed to contain safe

executables. The default is /usr/local/bin:/usr/

bin:/bin. Paranoid administrators may want to

redefine this list to remove /usr/local/bin, or

redefine it to nothing.

[1.3] --suexec-umask=UMASK

Specifies the maximum permissions allowed in the

[2.0] --with-suexec-umask=UMASK

user file-creation mask of the suExec executable as an

octal number. By default the serverís umask is used,

usually 022 (no group or other execute permission).

This is also the hard limit, and suExec will refuse to

even compile with a more generous setting. You can

make the event more restrictive, however. To have

suExec refuse to execute anything thatís group-

writable, world-writable, or world-readable, use a

umask of 026 (new in Apache 1.3.10).

This requirement of forcing suExec to be configured at compile time rather than runtime may seem more than a little inconvenient, but this deliberate inflexibility has more than a little to do with the fact that Apache has a very good reputation for security. If you compare this to the almost continual litany of exploits for some less popular proprietary Web servers that emphasize convenience over security, it becomes easier to put up with this relatively minor sort of inconvenience for the greater security it gives you.

To find out what settings an existing suExec binary has been compiled with, you can use the -V option, for example:

$ /usr/local/apache/bin/suexec -V
 -D AP_DOC_ROOT="/home/sites"
-D AP_HTTPD_USER="httpd"
-D AP_LOG_EXEC="/usr/local/apache/logs/cgi.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_USERDIR_SUFFIX="public_html"

suExec is installed into the bin directory (it moved here from the sbin directory since Apache 1.3.12; if these are set to the same place, the distinction is moot). Also, Apache 2 abstracts support for suExec within Apache itself into the new mod_suexec module and installs this into the configured libexec directory. This is potentially very handy because it allows you to disable suExec support by removing the module and add it later if you need it. Apache 1.3 doesnít allow you this freedom as it integrates suExec support into the core.

NOTE In this chapter Iíll cover building and installing of suExec. Iíll cover the configuration and set up of suExec in Chapter 6.

Configuring Apacheís Supporting Files and Scripts

As well as configuring the build process for Apache itself, configure also sets up the various supporting scripts and applications that come as standard with Apache. These range from shell scripts such as apachectl through Perl scripts such as dbmmanage and apxs to compiled binaries.

After the Apache executable has been built, the configuration process carries out some additional stages to clean it of unnecessary symbol information (useful for debugging but useless baggage for a production environment) and to substitute your configuration information into Apacheís supporting configuration files and scripts.

As with everything else, you can impose some control over this as well. Table 3-7 shows the options that control which of these stages are carried out by configure.

Table 3-7. Apache 1.3 Configure Options for Supporting Files and Scripts





The location of the local Perl interpreter. This is

Apache 1.3 only

required by several of Apacheís support scripts,

including apxs and dbmmanage. Normally, configure

works out the location automatically, but if Perl is

installed somewhere obscure or thereís more than

one interpreter, this option tells configure which

of the scripts to use.


Tells configure not to set up, compile, or install

Apache 1.3 only

any of the supporting applications.

--without-confadjust Tells configure not to substitute information

Apache 1.3 only

derived at the configuration stage into the

installed Apache configuration files.

In Apache 2, you can also choose whether those supporting tools that are built from source are linked statically or dynamically, in much the same way as you can choose the static or dynamic status of modules. All of these tools are built dynamically by default, but you can make some or all of them into statically linked executables with one of the options in Table 3-8. 

Table 3-8. Apache 2 Configure Options for Statically Linking Support Files and Scripts




All support executables are built statically.


The Apache benchmarking tool ab is built statically.


The group ID checking tool checkgid is built statically.


The DBM-based basic authentication password tool htdbm is

built statically.


The file-based digest authentication password tool htdigest

is built statically.


The file-based basic authentication password tool htpasswd

is built statically.


The IP to hostname DNS resolver logresolve is built



The log rotation tool rotatelogs is built statically.

>>> More Apache Articles          >>> More By Apress Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Apache Unveils Cassandra 1.2
- Apache on ARM Chips? Dell and Calxeda Help M...
- The Down Side of Open Source Software
- VMware Unveils Serengeti for Apache Hadoop
- SAP Takes Steps to Improve Hadoop Integration
- Looking to Hone Apache Hadoop Skills?
- How to Install Joomla on WAMPP
- Working with XAMPP and Wordpress
- GUI Available for Apache Camel
- Reduce Server Load for Apache and PHP Websit...
- Creating a VAMP (Vista, Apache, MySQL, PHP) ...
- Putting Apache in Jail
- Containing Intrusions in Apache
- Server Limits for Apache Security
- Setting Permissions in Apache

Developer Shed Affiliates


Dev Shed Tutorial Topics: