我有两台服务器。服务器 1 运行 Apache 2.2 和 mod_perl 2.0.4。服务器 2 运行 Apache 2.0 和 mod_perl 1.99。它们有几乎相同的配置文件。vhost 的 perl 部分如下所示：
<Location/perl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
选项 +ExecCGI
</Location>
如果我将 cgi 脚本放在服务器 2 的指定 perl 目录中，并将其权限设置为 644，则无法通过 Web 浏览器访问该文件。我收到 Forbidden 错误。这是我所期望的行为。我必须先将其权限设置为 755。
但是，如果我将保存脚本放在服务器 1 上的 cgi 脚本目录中，并将 chmodded 设置为 644，则服务器只会执行该脚本。它似乎并不关心文件的权限是什么，只关心目录的设置。
所有文件均归 root 所有并归其分组，apache 在单独的用户下运行。目录的 chmodded 为 755，也属于 root。
我的问题是，有没有办法使行为相同，这是否会对服务器 1 造成潜在的安全风险？或者我应该采用更好的方法来做到这一点？
答案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]>]
答案2
如果 ExecCGI 选项告诉 Apache 它可以执行目录中的 cgi，它就会执行。通常，Apache 运行 perl 脚本不需要可执行，只需可读即可。旧的 1.99 版 mod_perl 可能实现了类似 Apache“XBitHack”的功能，但这种行为现在不是标准的。你是说目录导致 403 错误的是 644？除了 root 之外，没有人可以导航到 644 目录，所以这是可以预料到的。但是如果你说文件是 644，并且目录至少是 111，那么 403 错误的原因可能是“XBitHack”或其他难以从给出的信息确定的原因。
较新的行为更安全、更灵活，因为通常最好最小化所有文件系统对象的权限，并且位于 ExecCGI 目录中的不可执行脚本只能由 Apache 执行。如果您不希望它们被执行，请不要将它们放入其中或不要设置 ExecCGI 选项。如果出于某种原因您想让它们还是 shell 可执行的，然后您可以设置该位。