When you suexec-enable your Apache Web server, a lot of behaviours change:

• CGI scripts in ScriptAliased directories will be executed under the identity of the username specified in the User and Group directives
• CGI scripts in user directories (as specified by the USERDIR_SUFFIX definition, set by the --suexec-userdir option) will be executed as the owning user if and only if
  1. the script was requested using the ~username syntax, and
  2. all of the ownership and permission requirements are met
  If the ~username URL format is used but the permissions/ownerships aren't correct, the result will be a '500 Internal Server Error' page, not the script being executed by the server user as in a non-suexec environment
• CGI scripts in all user directories accessed through ~username URLs will go through the suexec process--even those that you didn't consider or expect.

One effect of these changes is that previously-functioning user scripts may suddenly begin to fail, giving the visitor the fatal '500 Internal Server Error' page, and giving you, the Webmaster, an unrevealing "Premature end of script headers" message in the server error log. This is where it becomes easy to get frustrated by simply forgetting to check the suexec error log.

Another aspect of the use of suexec is that, if you have virtual hosts with different User or Group values, they cannot share ScriptAliased directories--because one of the requirements is that the script and the directory must be owned by the user and group suexec is being told to use. So you may have to duplicate a lot of your cgi-bin/ stuff into per-vhost directories that are owned and protected appropriately.

Frequently Asked Suexec Questions

The suexec wrapper isn't perfect, and some aspects of its design result in it being less than ideally suited to all environments. Here are some of the more common questions, changes, and enhancements that come up again and again:

Q:

The single --suexec-docroot value is irksome. I have 50 virtual hosts with DocumentRoot values like /vhost1, /vhost2, and so on. The only way I can get suexec to work with these is to use --suexec-docroot=/, which hardly seems secure.

A:

This is unfortunately the way it is with the suexec that comes with Apache up through version 1.3.11. The value you specify for --suexec-docroot must be an ancestor of all of the non-~username documents that use it. This restriction may be lifted in a future version, but even then it would require settings specified at compile-time, such as with something like --suexec-docroot=/vhost1,/vhost2.

Q:

I only want suexec to be used in certain directories or user accounts.

A:

As of Apache 1.3.11, suexec is an all-or-nothing proposition. If it's available and enabled, it will be used in all cases when a CGI script is invoked. A future version of Apache may provide a means of controlling this with greater granularity.

Q:

Why don't the Apache CGI error messages say there's a problem with suexec?

A:

Because Apache really doesn't know that for a fact. All it knows is that called an internal function to invoke the CGI, and the interaction with the script failed as described in the error message. The error might have been caused by a failure to meet suexec's requirements, or it may have been the result of a bona fide error in the script itself.

Q:

Why aren't suexec's error messages logged in the Apache server log?

A:

In order for the messages from suexec to appear in the main server's log, they would have to actually be passed to Apache so that Apache did the logging. Not only is this inappropriate for the Web server to do, but there would be additional confusion about into which error log the messages should go.

Next: Going Further »