我有两个发球员。 服务器1运行Apache 2.2和mod_perl 2.0.4。 服务器2运行Apache 2.0和mod_perl 1.99。 他们有几乎相同的conf文件。 虚拟主机的perl部分如下所示：
<Location/ perl>
SetHandler perl脚本
PerlResponseHandler ModPerl :: Registry
选项+ ExecCGI
</ Location>
如果我把一个cgi脚本放在服务器2的指定perl目录下，并且被修改为644，我就无法通过网页浏览器访问这个文件。 我得到Forbidden为错误。 这是我所期望的行为。 我必须先把它调到755。
但是，如果我将保存脚本放在服务器1上cgi脚本的目录中，并将其更改为644，则服务器只执行脚本。 它似乎不关心文件的权限只是目录设置的内容。
所有的文件都拥有和分组在根目录下，并且apache在单独的用户下运行。 该目录是chmodded 755，也属于根目录。
我的问题是，有没有办法使行为相同，这是服务器1上的潜在安全风险？ 还是有一个更好的方法，我应该这样做？
mod_perl不是CGI，所以+ ExecCGI和可执行权限都不重要。 你看到不同行为的原因是1.999_02 mod_perl开发人员改变了对可执行位的想法：
ModPerl::Registry no longer checks for -x bit (we don't executed scripts anyway), and thus works on acl-based filesystems. Also replaced the -r check with a proper error handling when the file is read in. [Damon Buckwalter <[email protected]>]
如果ExecCGI选项告诉Apache它可以在一个目录中执行一个cgi，它会的。 通常，perl脚本不需要是可执行的，Apache就可以运行它，只能读取。 mod_perl的老版本1.99可能实现了类似Apache的“XBitHack”，但是现在这种行为是非标准的。 你是说，给你一个403错误的目录是644？ 没有人可以导航到644目录，所以这是可以预料的。 但是如果你说的文件是644，目录至less是111，那么403错误的原因可能是'XBitHack'或其他难以确定的信息。
较新的行为更安全，更灵活，因为最大限度地减less所有文件系统对象的权限是一个好主意，位于ExecCGI目录中的非可执行脚本只能由Apache执行。 如果你不想要它们，不要把它们放在那里，或者不要设置ExecCGI选项。 如果由于某种原因，你想让它们也是 shell可执行的，那么你可以设置这个位。