Building Apache with suExec support - ApacheHave 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).
print this article SEARCH DEV SHED |
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.
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
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 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.
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
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
blog comments powered by Disqus | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Getting Started with Apache
