- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
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
binary. As of 1.3.11, though, it's part of the 'compiled modules' report
displayed by the '
% /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
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
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
suexecis 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/configurescript. Here they are:
- The presence of this option on the command line simply informs the
configurescript that you want the wrapper to be built as well. Without this option,
suexecwill not be built, even if there are other
suexecoptions on the command line.
- This mustbe the username under which your Apache server runs; that
is, the one specified on the
Userdirective outside all
suexecis 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
- 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
.cgifiles) 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.