pre-translation improvements

    protected from modification by non-root users. Not only must the files

    themselves be writeable only by root, but so must the directories, and

    parents of all directories. For example, if you choose to place

    ServerRoot in  /usr/local/apache then it is suggested that you create 

    that directory as root, with commands like these:</p>

    ServerRoot in  <code>/usr/local/apache</code> then it is suggested that

    you create that directory as root, with commands like these:</p>

    <example>

      mkdir /usr/local/apache <br />

      chmod 755 . bin conf logs

    </example>

    <p>It is assumed that /, /usr, and /usr/local are only modifiable by 

    root. When you install the <program>httpd</program> executable, you

    should ensure that it is similarly protected:</p>

    <p>It is assumed that <code>/</code>, <code>/usr</code>, and

    <code>/usr/local</code> are only modifiable by root. When you install the

    <program>httpd</program> executable, you should ensure that it is

    similarly protected:</p>

    <example>

      cp httpd /usr/local/apache/bin <br />

    significant.</p>

    <p>SSI files also pose the same risks that are associated with CGI

    scripts in general. Using the "exec cmd" element, SSI-enabled files 

    can execute any CGI script or program under the permissions of the 

    user and group Apache runs as, as configured in httpd.conf.</p>

    scripts in general. Using the <code>exec cmd</code> element, SSI-enabled

    files can execute any CGI script or program under the permissions of the

    user and group Apache runs as, as configured in

    <code>httpd.conf</code>.</p>

    <p>There are ways to enhance the security of SSI files while still

    taking advantage of the benefits they provide.</p>

    administrator can enable <a href="../suexec.html">suexec</a> as

    described in the <a href="#cgi">CGI in General</a> section.</p>

    <p>Enabling SSI for files with .html or .htm extensions can be 

    dangerous. This is especially true in a shared, or high traffic, 

    server environment. SSI-enabled files should have a separate extension,

    such as the conventional .shtml. This helps keep server load at a 

    minimum and allows for easier management of risk.</p>

    <p>Enabling SSI for files with <code>.html</code> or <code>.htm</code>

    extensions can be dangerous. This is especially true in a shared, or high

    traffic, server environment. SSI-enabled files should have a separate

    extension, such as the conventional <code>.shtml</code>. This helps keep

    server load at a minimum and allows for easier management of risk.</p>

    <p>Another solution is to disable the ability to run scripts and

    programs from SSI pages. To do this replace <code>Includes</code>

    with <code>IncludesNOEXEC</code> in the <directive

    module="core">Options</directive> directive.  Note that users may

    still use <--#include virtual="..." --> to execute CGI scripts if 

    these scripts are in directories designated by a <directive

    still use <code>&lt;--#include virtual="..." --&gt;</code> to execute CGI

    scripts if these scripts are in directories designated by a <directive

    module="mod_alias">ScriptAlias</directive> directive.</p>

  </section>

    <title>Other sources of dynamic content</title>

  <p>

  Embedded scripting options which run as part of the server itself,

  such as mod_php, mod_perl, mod_tcl, and mod_python, run under the

  identity of the server itself (see the <directive 

  module="mpm_common">User</directive> directive), and therefore

  scripts executed by these engines potentially can access anything the

  server user can. Some scripting engines may provide restrictions, but

  it is better to be safe and assume not.</p>

    <p>Embedded scripting options which run as part of the server itself,

    such as <code>mod_php</code>, <code>mod_perl</code>, <code>mod_tcl</code>,

    and <code>mod_python</code>, run under the identity of the server itself

    (see the <directive module="mpm_common">User</directive> directive), and

    therefore scripts executed by these engines potentially can access

    anything the server user can. Some scripting engines may provide

    restrictions, but it is better to be safe and assume not.</p>

  </section>

    <p>Also be wary of playing games with the <directive

    module="mod_userdir">UserDir</directive> directive; setting it to

    something like "./" would have the same effect, for root, as the first 

    example above. If you are using Apache 1.3 or above, we strongly 

    something like <code>./</code> would have the same effect, for root, as

    the first example above. If you are using Apache 1.3 or above, we strongly

    recommend that you include the following line in your server

    configuration files:</p>