1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?>
4 <!-- $LastChangedRevision$ -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <manualpage metafile="suexec.xml.meta">
25 <title>suEXEC Support</title>
28 <p>The <strong>suEXEC</strong> feature provides users of the Apache
29 HTTP Server the ability
30 to run <strong>CGI</strong> and <strong>SSI</strong> programs
31 under user IDs different from the user ID of the calling
32 web server. Normally, when a CGI or SSI program executes, it
33 runs as the same user who is running the web server.</p>
35 <p>Used properly, this feature can reduce
36 considerably the security risks involved with allowing users to
37 develop and run private CGI or SSI programs. However, if suEXEC
38 is improperly configured, it can cause any number of problems
39 and possibly create new holes in your computer's security. If
40 you aren't familiar with managing <em>setuid root</em> programs
41 and the security issues they present, we highly recommend that
42 you not consider using suEXEC.</p>
45 <section id="before"><title>Before we begin</title>
47 <p>Before jumping head-first into this document,
48 you should be aware that certain assumptions are made about you and
49 the environment in which you will be using suexec.</p>
51 <p>First, it is assumed that you are using a UNIX
52 derivative operating system that is capable of
53 <strong>setuid</strong> and <strong>setgid</strong> operations.
54 All command examples are given in this regard. Other platforms,
55 if they are capable of supporting suEXEC, may differ in their
58 <p>Second, it is assumed you are familiar with
59 some basic concepts of your computer's security and its
60 administration. This involves an understanding of
61 <strong>setuid/setgid</strong> operations and the various
62 effects they may have on your system and its level of
65 <p>Third, it is assumed that you are using an
66 <strong>unmodified</strong> version of suEXEC code. All code
67 for suEXEC has been carefully scrutinized and tested by the
68 developers as well as numerous beta testers. Every precaution
69 has been taken to ensure a simple yet solidly safe base of
70 code. Altering this code can cause unexpected problems and new
71 security risks. It is <strong>highly</strong> recommended you
72 not alter the suEXEC code unless you are well versed in the
73 particulars of security programming and are willing to share
74 your work with the Apache HTTP Server development team for consideration.</p>
76 <p>Fourth, and last, it has been the decision of
77 the Apache HTTP Server development team to <strong>NOT</strong> make suEXEC part of
78 the default installation of Apache httpd. To this end, suEXEC
79 configuration requires of the administrator careful attention
80 to details. After due consideration has been given to the
81 various settings for suEXEC, the administrator may install
82 suEXEC through normal installation methods. The values for
83 these settings need to be carefully determined and specified by
84 the administrator to properly maintain system security during
85 the use of suEXEC functionality. It is through this detailed
86 process that we hope to limit suEXEC
87 installation only to those who are careful and determined
90 <p>Still with us? Yes? Good. Let's move on!</p>
93 <section id="model"><title>suEXEC Security Model</title>
95 <p>Before we begin configuring and installing
96 suEXEC, we will first discuss the security model you are about
97 to implement. By doing so, you may better understand what
98 exactly is going on inside suEXEC and what precautions are
99 taken to ensure your system's security.</p>
101 <p><strong>suEXEC</strong> is based on a setuid
102 "wrapper" program that is called by the main Apache HTTP Server.
103 This wrapper is called when an HTTP request is made for a CGI
104 or SSI program that the administrator has designated to run as
105 a userid other than that of the main server. When such a
106 request is made, Apache httpd provides the suEXEC wrapper with the
107 program's name and the user and group IDs under which the
108 program is to execute.</p>
110 <p>The wrapper then employs the following process
111 to determine success or failure -- if any one of these
112 conditions fail, the program logs the failure and exits with an
113 error, otherwise it will continue:</p>
117 <strong>Is the user executing this wrapper a valid user of
118 this system?</strong>
121 This is to ensure that the user executing the wrapper is
122 truly a user of the system.
127 <strong>Was the wrapper called with the proper number of
131 The wrapper will only execute if it is given the proper
132 number of arguments. The proper argument format is known
133 to the Apache HTTP Server. If the wrapper is not receiving
134 the proper number of arguments, it is either being
135 hacked, or there is something wrong with the suEXEC
136 portion of your Apache httpd binary.
141 <strong>Is this valid user allowed to run the
145 Is this user the user allowed to run this wrapper? Only
146 one user (the Apache user) is allowed to execute this
152 <strong>Does the target CGI or SSI program have an unsafe
153 hierarchical reference?</strong>
156 Does the target CGI or SSI program's path contain a leading
157 '/' or have a '..' backreference? These are not allowed; the
158 target CGI/SSI program must reside within suEXEC's document
159 root (see <code>--with-suexec-docroot=<em>DIR</em></code>
165 <strong>Is the target user name valid?</strong>
168 Does the target user exist?
173 <strong>Is the target group name valid?</strong>
176 Does the target group exist?
181 <strong>Is the target user <em>NOT</em> superuser?</strong>
185 suEXEC does not allow <code><em>root</em></code>
186 to execute CGI/SSI programs.
191 <strong>Is the target userid <em>ABOVE</em> the minimum ID
195 The minimum user ID number is specified during
196 configuration. This allows you to set the lowest possible
197 userid that will be allowed to execute CGI/SSI programs.
198 This is useful to block out "system" accounts.
203 <strong>Is the target group <em>NOT</em> the superuser
207 Presently, suEXEC does not allow the <code><em>root</em></code>
208 group to execute CGI/SSI programs.
213 <strong>Is the target groupid <em>ABOVE</em> the minimum ID
217 The minimum group ID number is specified during
218 configuration. This allows you to set the lowest possible
219 groupid that will be allowed to execute CGI/SSI programs.
220 This is useful to block out "system" groups.
225 <strong>Can the wrapper successfully become the target user
229 Here is where the program becomes the target user and
230 group via setuid and setgid calls. The group access list
231 is also initialized with all of the groups of which the
237 <strong>Can we change directory to the one in which the target
238 CGI/SSI program resides?</strong>
241 If it doesn't exist, it can't very well contain files. If we
242 can't change directory to it, it might as well not exist.
247 <strong>Is the directory within the httpd webspace?</strong>
250 If the request is for a regular portion of the server, is
251 the requested directory within suEXEC's document root? If
252 the request is for a <directive module="mod_userdir"
253 >UserDir</directive>, is the requested directory
254 within the directory configured as suEXEC's userdir (see
255 <a href="#install">suEXEC's configuration options</a>)?
260 <strong>Is the directory <em>NOT</em> writable by anyone
264 We don't want to open up the directory to others; only
265 the owner user may be able to alter this directories
271 <strong>Does the target CGI/SSI program exist?</strong>
274 If it doesn't exists, it can't very well be executed.
279 <strong>Is the target CGI/SSI program <em>NOT</em> writable
280 by anyone else?</strong>
283 We don't want to give anyone other than the owner the
284 ability to change the CGI/SSI program.
289 <strong>Is the target CGI/SSI program <em>NOT</em> setuid or
293 We do not want to execute programs that will then change
299 <strong>Is the target user/group the same as the program's
303 Is the user the owner of the file?
308 <strong>Can we successfully clean the process environment
309 to ensure safe operations?</strong>
312 suEXEC cleans the process' environment by establishing a
313 safe execution PATH (defined during configuration), as
314 well as only passing through those variables whose names
315 are listed in the safe environment list (also created
316 during configuration).
321 <strong>Can we successfully become the target CGI/SSI program
322 and execute?</strong>
325 Here is where suEXEC ends and the target CGI/SSI program begins.
330 <p>This is the standard operation of the
331 suEXEC wrapper's security model. It is somewhat stringent and
332 can impose new limitations and guidelines for CGI/SSI design,
333 but it was developed carefully step-by-step with security in
336 <p>For more information as to how this security
337 model can limit your possibilities in regards to server
338 configuration, as well as what security risks can be avoided
339 with a proper suEXEC setup, see the <a
340 href="#jabberwock">"Beware the Jabberwock"</a> section of this
344 <section id="install"><title>Configuring & Installing
347 <p>Here's where we begin the fun.</p>
349 <p><strong>suEXEC configuration
350 options</strong><br />
354 <dt><code>--enable-suexec</code></dt>
356 <dd>This option enables the suEXEC feature which is never
357 installed or activated by default. At least one
358 <code>--with-suexec-xxxxx</code> option has to be provided
359 together with the <code>--enable-suexec</code> option to let
360 APACI accept your request for using the suEXEC feature.</dd>
362 <dt><code>--enable-suexec-capabilities</code></dt>
364 <dd><strong>Linux specific:</strong> Normally,
365 the <code>suexec</code> binary is installed "setuid/setgid
366 root", which allows it to run with the full privileges of the
367 root user. If this option is used, the <code>suexec</code>
368 binary will instead be installed with only the setuid/setgid
369 "capability" bits set, which is the subset of full root
370 priviliges required for suexec operation. Note that
371 the <code>suexec</code> binary may not be able to write to a log
372 file in this mode; it is recommended that the
373 <code>--with-suexec-syslog --without-suexec-logfile</code>
374 options are used in conjunction with this mode, so that syslog
375 logging is used instead.</dd>
377 <dt><code>--with-suexec-bin=<em>PATH</em></code></dt>
379 <dd>The path to the <code>suexec</code> binary must be hard-coded
380 in the server for security reasons. Use this option to override
381 the default path. <em>e.g.</em>
382 <code>--with-suexec-bin=/usr/sbin/suexec</code></dd>
384 <dt><code>--with-suexec-caller=<em>UID</em></code></dt>
386 <dd>The <a href="mod/mpm_common.html#user">username</a> under which
387 httpd normally runs. This is the only user allowed to
388 execute the suEXEC wrapper.</dd>
390 <dt><code>--with-suexec-userdir=<em>DIR</em></code></dt>
392 <dd>Define to be the subdirectory under users' home
393 directories where suEXEC access should be allowed. All
394 executables under this directory will be executable by suEXEC
395 as the user so they should be "safe" programs. If you are
396 using a "simple" <directive module="mod_userdir">UserDir</directive>
397 directive (ie. one without a "*" in it) this should be set to the same
398 value. suEXEC will not work properly in cases where the <directive
399 module="mod_userdir">UserDir</directive> directive points to
400 a location that is not the same as the user's home directory
401 as referenced in the <code>passwd</code> file. Default value is
402 "<code>public_html</code>".<br />
403 If you have virtual hosts with a different <directive
404 module="mod_userdir">UserDir</directive> for each,
405 you will need to define them to all reside in one parent
406 directory; then name that parent directory here. <strong>If
407 this is not defined properly, "~userdir" cgi requests will
408 not work!</strong></dd>
410 <dt><code>--with-suexec-docroot=<em>DIR</em></code></dt>
412 <dd>Define as the DocumentRoot set for httpd. This will be
413 the only hierarchy (aside from <directive module="mod_userdir"
414 >UserDir</directive>s) that can be used for suEXEC behavior. The
415 default directory is the <code>--datadir</code> value with the suffix
416 "<code>/htdocs</code>", <em>e.g.</em> if you configure with
417 "<code>--datadir=/home/apache</code>" the directory
418 "<code>/home/apache/htdocs</code>" is used as document root for the
421 <dt><code>--with-suexec-uidmin=<em>UID</em></code></dt>
423 <dd>Define this as the lowest UID allowed to be a target user
424 for suEXEC. For most systems, 500 or 100 is common. Default
427 <dt><code>--with-suexec-gidmin=<em>GID</em></code></dt>
429 <dd>Define this as the lowest GID allowed to be a target
430 group for suEXEC. For most systems, 100 is common and
431 therefore used as default value.</dd>
433 <dt><code>--with-suexec-logfile=<em>FILE</em></code></dt>
435 <dd>This defines the filename to which all suEXEC
436 transactions and errors are logged (useful for auditing and
437 debugging purposes). By default the logfile is named
438 "<code>suexec_log</code>" and located in your standard logfile
439 directory (<code>--logfiledir</code>).</dd>
441 <dt><code>--with-suexec-syslog</code></dt>
443 <dd>If defined, suexec will log notices and errors to syslog
444 instead of a logfile. This option must be combined
445 with <code>--without-suexec-logfile</code>.</dd>
447 <dt><code>--with-suexec-safepath=<em>PATH</em></code></dt>
449 <dd>Define a safe PATH environment to pass to CGI
450 executables. Default value is
451 "<code>/usr/local/bin:/usr/bin:/bin</code>".</dd>
455 <title>Compiling and installing the suEXEC wrapper</title>
457 <p>If you have enabled the suEXEC feature with the
458 <code>--enable-suexec</code> option the <code>suexec</code> binary
459 (together with httpd itself) is automatically built if you execute
460 the <code>make</code> command.</p>
462 <p>After all components have been built you can execute the
463 command <code>make install</code> to install them. The binary image
464 <code>suexec</code> is installed in the directory defined by the
465 <code>--sbindir</code> option. The default location is
466 "/usr/local/apache2/bin/suexec".</p>
468 <p>Please note that you need <strong><em>root
469 privileges</em></strong> for the installation step. In order
470 for the wrapper to set the user ID, it must be installed as
471 owner <code><em>root</em></code> and must have the setuserid
472 execution bit set for file modes.</p>
476 <title>Setting paranoid permissions</title>
478 <p>Although the suEXEC wrapper will check to ensure that its
479 caller is the correct user as specified with the
480 <code>--with-suexec-caller</code> <program>configure</program>
482 always the possibility that a system or library call suEXEC uses
483 before this check may be exploitable on your system. To counter
484 this, and because it is best-practise in general, you should use
485 filesystem permissions to ensure that only the group httpd
486 runs as may execute suEXEC.</p>
488 <p>If for example, your web server is configured to run as:</p>
490 <highlight language="config">
495 <p>and <program>suexec</program> is installed at
496 "/usr/local/apache2/bin/suexec", you should run:</p>
499 chgrp webgroup /usr/local/apache2/bin/suexec<br />
500 chmod 4750 /usr/local/apache2/bin/suexec<br />
503 <p>This will ensure that only the group httpd runs as can even
504 execute the suEXEC wrapper.</p>
509 <section id="enable"><title>Enabling & Disabling
512 <p>Upon startup of httpd, it looks for the file
513 <program>suexec</program> in the directory defined by the
514 <code>--sbindir</code> option (default is
515 "/usr/local/apache/sbin/suexec"). If httpd finds a properly
516 configured suEXEC wrapper, it will print the following message
517 to the error log:</p>
520 [notice] suEXEC mechanism enabled (wrapper: <var>/path/to/suexec</var>)
523 <p>If you don't see this message at server startup, the server is
524 most likely not finding the wrapper program where it expects
525 it, or the executable is not installed <em>setuid root</em>.</p>
527 <p>If you want to enable the suEXEC mechanism for the first time
528 and an Apache HTTP Server is already running you must kill and
529 restart httpd. Restarting it with a simple HUP or USR1 signal
530 will not be enough. </p>
531 <p>If you want to disable suEXEC you should kill and restart
532 httpd after you have removed the <program>suexec</program> file.</p>
535 <section id="usage"><title>Using suEXEC</title>
537 <p>Requests for CGI programs will call the suEXEC wrapper only if
538 they are for a virtual host containing a <directive
539 module="mod_suexec">SuexecUserGroup</directive> directive or if
540 they are processed by <module>mod_userdir</module>.</p>
542 <p><strong>Virtual Hosts:</strong><br /> One way to use the suEXEC
543 wrapper is through the <directive
544 module="mod_suexec">SuexecUserGroup</directive> directive in
545 <directive module="core">VirtualHost</directive> definitions. By
546 setting this directive to values different from the main server
547 user ID, all requests for CGI resources will be executed as the
548 <em>User</em> and <em>Group</em> defined for that <directive
549 module="core" type="section">VirtualHost</directive>. If this
550 directive is not specified for a <directive module="core"
551 type="section">VirtualHost</directive> then the main server userid
554 <p><strong>User directories:</strong><br /> Requests that are
555 processed by <module>mod_userdir</module> will call the suEXEC
556 wrapper to execute CGI programs under the userid of the requested
557 user directory. The only requirement needed for this feature to
558 work is for CGI execution to be enabled for the user and that the
559 script must meet the scrutiny of the <a href="#model">security
560 checks</a> above. See also the
561 <code>--with-suexec-userdir</code> <a href="#install">compile
562 time option</a>.</p> </section>
564 <section id="debug"><title>Debugging suEXEC</title>
566 <p>The suEXEC wrapper will write log information
567 to the file defined with the <code>--with-suexec-logfile</code>
568 option as indicated above, or to syslog if <code>--with-suexec-syslog</code>
569 is used. If you feel you have configured and
570 installed the wrapper properly, have a look at the log and the
571 error_log for the server to see where you may have gone astray.
572 The output of <code>"suexec -V"</code> will show the options
573 used to compile suexec, if using a binary distribution.</p>
577 <section id="jabberwock"><title>Beware the Jabberwock:
578 Warnings & Examples</title>
580 <p><strong>NOTE!</strong> This section may not be
581 complete. For the latest revision of this section of the
582 documentation, see the <a
583 href="http://httpd.apache.org/docs/&httpd.docs;/suexec.html">Online
584 Documentation</a> version.</p>
586 <p>There are a few points of interest regarding
587 the wrapper that can cause limitations on server setup. Please
588 review these before submitting any "bugs" regarding suEXEC.</p>
591 <li><strong>suEXEC Points Of Interest</strong></li>
594 Hierarchy limitations
597 For security and efficiency reasons, all suEXEC requests
598 must remain within either a top-level document root for
599 virtual host requests, or one top-level personal document
600 root for userdir requests. For example, if you have four
601 VirtualHosts configured, you would need to structure all
602 of your VHosts' document roots off of one main httpd
603 document hierarchy to take advantage of suEXEC for
604 VirtualHosts. (Example forthcoming.)
609 suEXEC's PATH environment variable
612 This can be a dangerous thing to change. Make certain
613 every path you include in this define is a
614 <strong>trusted</strong> directory. You don't want to
615 open people up to having someone from across the world
616 running a trojan horse on them.
621 Altering the suEXEC code
624 Again, this can cause <strong>Big Trouble</strong> if you
625 try this without knowing what you are doing. Stay away
626 from it if at all possible.