我有编程背景，由于我们的注册系统管理员出现紧急情况，我被派去管理工作中的 Linux 服务器。将我们的 PHP 文件归 root 所有，而 Apache 显然在 Fedora 8 上以 apache 的形式运行，这样做可靠或安全吗？
Apache 被授予读取的权限，在上传目录等少数情况下，通过 chmod 777 授予该上传文件夹的写入权限。
我们正在运行 mod_security，但想知道是否有更好的做法。在接下来的 2-3 周内，系统管理员正在休养，我将独自处理此事。
答案1
哪个组拥有 PHP 文件？您提到的 777 表明它是“wheel”或“adm”或其他特权组，因此 Apache 可以看到任何文件的唯一方式是该文件是全球可读的。或者，对于 uploads 文件夹来说，是全球可写的。
这几乎肯定不是一件好事——尽管严重程度取决于您在服务器上运行的所有内容（基于 Web 和其他内容）、任何 PHP 脚本是否包含纯文本凭据等。
另一方面，如果文件归 Apache 所运行的 gid 所有，那么您的情况会好一些。理论上，您可以在chmod -R o-rwxDocumentRoot 上执行删除所有“世界”权限的操作，这样一切都会很顺利、安全，您的网页仍会正常工作。
但接下来还有 setuid 位的问题。我不确定 root 拥有的 PHP 脚本在启用 setuid 的情况下是否会被恶意利用，但我不希望在我的 Web 服务器上出现这样的脚本。
并且，即使 setuid 不是问题，root 所有权对我来说仍然不对劲。
答案2
如果您以 Apache 用户身份运行 PHP（即 debian 系统上的“www-data”、CentOS+cPanel 共享主机上的“nobody”等），那么从通过 Apache - PHP 调用的角度来看，文件的所有者并不重要，因此脚本将始终以 Apache 用户身份运行，而不是以拥有文件的用户身份运行。
如果您将 PHP 作为模块运行，那么几乎肯定是这种情况。
如果您将 PHP 配置为以特定用户身份运行脚本（通过 suphp、suexec 或类似方式 - 如果您通过 CGI 或 FastCGI 方法运行 PHP，您可能会这样做），那么让特权用户拥有脚本文件是一个非常糟糕的主意。
至于“777”权限，也应该避免，特别是如果您不是服务器上的唯一用户。相反，我会确保目录归 Apache 将以之运行 PHP 的用户所有，并使用“700”（或归该用户所在的组，并使用 770）。更严谨的是，如果您的脚本始终知道它们想要的文件名，并且不需要读取目录列表，则也禁止对该目录的执行权限。
也不要让脚本为全球可写。默认的 suPHP 设置实际上可以稍微保护您免受这种情况的影响，方法是拒绝运行具有全球可写权限（或位于全球可写目录中）的脚本。
作为一般规则，我会避免在开发中使用比在公开可用的实时环境中所需的权限更少的权限。这可以避免在将代码发布到实时环境中时意外地将权限放得太宽，并避免引入错误，因为您的代码假设的访问权限比实时环境中允许的权限更宽。
答案3
对于 PHP 脚本来说，777 权限通常被认为是一个坏主意。如果文件归 root 用户所有，您可能希望它们至少归 apache 组所有，这样它们就不必是全局可读的（如果这不是您想要的）。这样，您可以缩减到 770 权限。（脚本一开始就归 root 所有似乎也有点奇怪。）
将来，您可能还想在目录上设置粘滞位，以确保添加到该目录的新文件自动更改到拥有该目录的组，使用以下命令：
chmod 2775 /路径/到/目录
这样，您可以（例如）将您为 apache 提供的目录的组所有者设置为 apache，并且添加的新内容将自动位于 apache 组中，因此可读，而无需授予全球可读的权限（假设适当的 umask）。