suexec.html.en

Apache_2.0.59-Openssl_0.9 配置tomcat. Apache_2.0.59-Openssl_0.9 配置tomcat.

        </p>
      </li>

      <li>
        <strong>Is the target user/group the same as the program's
        user/group?</strong> 

        <p class="indent">
          Is the user the owner of the file?
        </p>
      </li>

      <li>
        <strong>Can we successfully clean the process environment
        to ensure safe operations?</strong> 

        <p class="indent">
          suEXEC cleans the process' environment by establishing a
          safe execution PATH (defined during configuration), as
          well as only passing through those variables whose names
          are listed in the safe environment list (also created
          during configuration).
        </p>
      </li>

      <li>
        <strong>Can we successfully become the target CGI/SSI program
        and execute?</strong> 

        <p class="indent">
          Here is where suEXEC ends and the target CGI/SSI program begins.
        </p>
      </li>
    </ol>

    <p>This is the standard operation of the
    suEXEC wrapper's security model. It is somewhat stringent and
    can impose new limitations and guidelines for CGI/SSI design,
    but it was developed carefully step-by-step with security in
    mind.</p>

    <p>For more information as to how this security
    model can limit your possibilities in regards to server
    configuration, as well as what security risks can be avoided
    with a proper suEXEC setup, see the <a href="#jabberwock">"Beware the Jabberwock"</a> section of this
    document.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="install" id="install">Configuring &amp; Installing
    suEXEC</a></h2>

    <p>Here's where we begin the fun.</p>

    <p><strong>suEXEC configuration
    options</strong><br />
    </p>

    <dl>
      <dt><code>--enable-suexec</code></dt>

      <dd>This option enables the suEXEC feature which is never
      installed or activated by default. At least one
      <code>--with-suexec-xxxxx</code> option has to be provided
      together with the <code>--enable-suexec</code> option to let
      APACI accept your request for using the suEXEC feature.</dd>

      <dt><code>--with-suexec-bin=<em>PATH</em></code></dt>

      <dd>The path to the <code>suexec</code> binary must be hard-coded
      in the server for security reasons. Use this option to override
      the default path. <em>e.g.</em>
      <code>--with-suexec-bin=/usr/sbin/suexec</code></dd>

      <dt><code>--with-suexec-caller=<em>UID</em></code></dt>

      <dd>The <a href="mod/mpm_common.html#user">username</a> under which
      Apache normally runs. This is the only user allowed to
      execute this program.</dd>

      <dt><code>--with-suexec-userdir=<em>DIR</em></code></dt>

      <dd>Define to be the subdirectory under users' home
      directories where suEXEC access should be allowed. All
      executables under this directory will be executable by suEXEC
      as the user so they should be "safe" programs. If you are
      using a "simple" UserDir directive (ie. one without a "*" in
      it) this should be set to the same value. suEXEC will not
      work properly in cases where the UserDir directive points to
      a location that is not the same as the user's home directory
      as referenced in the passwd file. Default value is
      "public_html".<br />
       If you have virtual hosts with a different UserDir for each,
      you will need to define them to all reside in one parent
      directory; then name that parent directory here. <strong>If
      this is not defined properly, "~userdir" cgi requests will
      not work!</strong></dd>

      <dt><code>--with-suexec-docroot=<em>DIR</em></code></dt>

      <dd>Define as the DocumentRoot set for Apache. This will be
      the only hierarchy (aside from UserDirs) that can be used for
      suEXEC behavior. The default directory is the <code>--datadir</code>
      value with the suffix "/htdocs", <em>e.g.</em> if you configure
      with "<code>--datadir=/home/apache</code>" the directory
      "/home/apache/htdocs" is used as document root for the suEXEC
      wrapper.</dd>

      <dt><code>--with-suexec-uidmin=<em>UID</em></code></dt>

      <dd>Define this as the lowest UID allowed to be a target user
      for suEXEC. For most systems, 500 or 100 is common. Default
      value is 100.</dd>

      <dt><code>--with-suexec-gidmin=<em>GID</em></code></dt>

      <dd>Define this as the lowest GID allowed to be a target
      group for suEXEC. For most systems, 100 is common and
      therefore used as default value.</dd>

      <dt><code>--with-suexec-logfile=<em>FILE</em></code></dt>

      <dd>This defines the filename to which all suEXEC
      transactions and errors are logged (useful for auditing and
      debugging purposes). By default the logfile is named
      "suexec_log" and located in your standard logfile directory
      (<code>--logfiledir</code>).</dd>

      <dt><code>--with-suexec-safepath=<em>PATH</em></code></dt>

      <dd>Define a safe PATH environment to pass to CGI
      executables. Default value is
      "/usr/local/bin:/usr/bin:/bin".</dd>
    </dl>

    <p><strong>Compiling and installing the suEXEC
    wrapper</strong><br />
     If you have enabled the suEXEC feature with the
    <code>--enable-suexec</code> option the <code>suexec</code> binary
    (together with Apache itself) is automatically built if you execute
    the <code>make</code> command.<br />
     After all components have been built you can execute the
    command <code>make install</code> to install them. The binary image
    <code>suexec</code> is installed in the directory defined by the
    <code>--sbindir</code> option. The default location is
    "/usr/local/apache2/sbin/suexec".<br />
     Please note that you need <strong><em>root
    privileges</em></strong> for the installation step. In order
    for the wrapper to set the user ID, it must be installed as
    owner <code><em>root</em></code> and must have the setuserid
    execution bit set for file modes.</p>

    <p><strong>Setting paranoid permissions</strong><br />
    Although the suEXEC wrapper will check to ensure that its
    caller is the correct user as specified with the
    <code>--with-suexec-caller</code> <code class="program"><a href="./programs/configure.html">configure</a></code>
    option, there is
    always the possibility that a system or library call suEXEC uses
    before this check may be exploitable on your system. To counter
    this, and because it is best-practise in general, you should use 
    filesystem permissions to ensure that only the group Apache 
    runs as may execute suEXEC.</p>

    <p>If for example, your web-server is configured to run as:</p>

<div class="example"><p><code>
    User www<br />
    Group webgroup<br />
</code></p></div>

    <p>and <code class="program"><a href="./programs/suexec.html">suexec</a></code> is installed at
    "/usr/local/apache2/sbin/suexec", you should run:</p>

<div class="example"><p><code>
    chgrp webgroup /usr/local/apache2/bin/suexec<br />
    chmod 4750 /usr/local/apache2/bin/suexec<br />
</code></p></div>

    <p>This will ensure that only the group Apache runs as can even
    execute the suEXEC wrapper.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="enable" id="enable">Enabling &amp; Disabling
    suEXEC</a></h2>

    <p>Upon startup of Apache, it looks for the file
    <code class="program"><a href="./programs/suexec.html">suexec</a></code> in the directory defined by the
    <code>--sbindir</code> option (default is
    "/usr/local/apache/sbin/suexec"). If Apache finds a properly
    configured suEXEC wrapper, it will print the following message
    to the error log:</p>

<div class="example"><p><code>
    [notice] suEXEC mechanism enabled (wrapper: <var>/path/to/suexec</var>)
</code></p></div>

    <p>If you don't see this message at server startup, the server is
    most likely not finding the wrapper program where it expects
    it, or the executable is not installed <em>setuid root</em>.</p>

     <p>If you want to enable the suEXEC mechanism for the first time
    and an Apache server is already running you must kill and
    restart Apache. Restarting it with a simple HUP or USR1 signal
    will not be enough. </p>
     <p>If you want to disable suEXEC you should kill and restart
    Apache after you have removed the <code class="program"><a href="./programs/suexec.html">suexec</a></code> file.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="usage" id="usage">Using suEXEC</a></h2>

    <p>Requests for CGI programs will call the suEXEC wrapper only if
    they are for a virtual host containing a <code class="directive"><a href="./mod/mod_suexec.html#suexecusergroup">SuexecUserGroup</a></code> directive or if
    they are processed by <code class="module"><a href="./mod/mod_userdir.html">mod_userdir</a></code>.</p>

    <p><strong>Virtual Hosts:</strong><br /> One way to use the suEXEC
    wrapper is through the <code class="directive"><a href="./mod/mod_suexec.html#suexecusergroup">SuexecUserGroup</a></code> directive in
    <code class="directive"><a href="./mod/core.html#virtualhost">VirtualHost</a></code> definitions.  By
    setting this directive to values different from the main server
    user ID, all requests for CGI resources will be executed as the
    <em>User</em> and <em>Group</em> defined for that <code class="directive"><a href="./mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></code>. If this
    directive is not specified for a <code class="directive"><a href="./mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></code> then the main server userid
    is assumed.</p>

    <p><strong>User directories:</strong><br /> Requests that are
     processed by <code class="module"><a href="./mod/mod_userdir.html">mod_userdir</a></code> will call the suEXEC
     wrapper to execute CGI programs under the userid of the requested
     user directory.  The only requirement needed for this feature to
     work is for CGI execution to be enabled for the user and that the
     script must meet the scrutiny of the <a href="#model">security
     checks</a> above.  See also the
     <code>--with-suexec-userdir</code> <a href="#install">compile
     time option</a>.</p> </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="debug" id="debug">Debugging suEXEC</a></h2>

    <p>The suEXEC wrapper will write log information
    to the file defined with the <code>--with-suexec-logfile</code>
    option as indicated above. If you feel you have configured and
    installed the wrapper properly, have a look at this log and the
    error_log for the server to see where you may have gone astray.</p>

</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="jabberwock" id="jabberwock">Beware the Jabberwock:
    Warnings &amp; Examples</a></h2>

    <p><strong>NOTE!</strong> This section may not be
    complete. For the latest revision of this section of the
    documentation, see the Apache Group's <a href="http://httpd.apache.org/docs/2.0/suexec.html">Online
    Documentation</a> version.</p>

    <p>There are a few points of interest regarding
    the wrapper that can cause limitations on server setup. Please
    review these before submitting any "bugs" regarding suEXEC.</p>

    <ul>
      <li><strong>suEXEC Points Of Interest</strong></li>

      <li>
        Hierarchy limitations 

        <p class="indent">
          For security and efficiency reasons, all suEXEC requests
          must remain within either a top-level document root for
          virtual host requests, or one top-level personal document
          root for userdir requests. For example, if you have four
          VirtualHosts configured, you would need to structure all
          of your VHosts' document roots off of one main Apache
          document hierarchy to take advantage of suEXEC for
          VirtualHosts. (Example forthcoming.)
        </p>
      </li>

      <li>
        suEXEC's PATH environment variable 

        <p class="indent">
          This can be a dangerous thing to change. Make certain
          every path you include in this define is a
          <strong>trusted</strong> directory. You don't want to
          open people up to having someone from across the world
          running a trojan horse on them.
        </p>
      </li>

      <li>
        Altering the suEXEC code 

        <p class="indent">
          Again, this can cause <strong>Big Trouble</strong> if you
          try this without knowing what you are doing. Stay away
          from it if at all possible.
        </p>
      </li>
    </ul>

</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="./en/suexec.html" title="English">&nbsp;en&nbsp;</a> |
<a href="./ja/suexec.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
<a href="./ko/suexec.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2006 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="./faq/">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a></p></div>
</body></html>