开发背景，安全地拥有root拥有的php文件，但是Apache不同的用户？

Question

我来自一个编程背景，因为我们的reg管理员出现了紧急情况，所以我被抛到了管理Linux服务器的工作中。让root拥有我们的PHP文件，而apache显然以Apache的身份在Fedora 8上运行，这是可靠还是安全的？

Apache被授予读取权限，在较小的情况下，如上载目录，则由chmod 777为该上载文件夹编写权限。

我们正在运行mod_security，但不知道是否有更好的实践。在接下来的2-3周里，只有我一个人在做这件事，而系统管理员正在恢复。

Answer 1

哪些组拥有PHP文件？您提到的777表明它是“轮子”或“adm”或其他一些特权组，因此Apache查看任何文件的唯一方法是当该文件具有世界可读性时。或世界可写，在上传文件夹的情况下。

这几乎肯定不是件好事--尽管严重程度将取决于您在服务器上运行的所有内容(包括基于web的和其他的)，是否有任何PHP脚本包含明文凭据，等等。

另一方面，如果这些文件是Apache运行的gid所拥有的，那么您的状态就更好了。理论上，您可以在chmod -R o-rwx on DocumentRoot上删除所有"world“特权，而且一切都很可能是好的和安全的，并且您的网页仍然可以工作。

但还有一个问题，就是setuid比特。我不确定一个根拥有的带有setuid的PHP脚本是否会被恶意利用，但我不想在我的web服务器上使用。

即使setuid不受关注，根本的所有权对我来说还是不正确的。

Answer 2

如果您以Apache的用户身份运行PHP (即debian系统上的"www-data“，CentOS+cPanel共享主机上的”无人“，.)然后文件的所有者通过Apache调用PoV并不重要，因此脚本将始终以Apache用户的身份运行，而不是作为拥有文件的用户运行。

如果您将PHP作为一个模块运行，那么几乎可以肯定是这样的。

如果PHP配置为以特定用户的身份运行脚本(通过suphp、suexec或类似的方式运行脚本--如果通过CGI或FastCGI方法运行PHP，则让特权用户拥有脚本文件是一个非常糟糕的想法。

至于"777“权限，也应该避免这一点，特别是如果您不是服务器上的唯一用户。相反，我要确保目录是用户拥有的，Apache将运行PHP并使用"700“(或者在这个用户也在其中并使用770的组中)。对于更大的偏执，如果您的脚本总是知道它们想要的文件名，并且不需要读取目录列表，也不允许对目录执行权限。

也从来没有脚本世界-可写。默认的suPHP设置实际上可以通过拒绝使用具有全局可写权限(或者在目录中是可写的)的权限运行脚本来保护您免受这种情况的影响。

一般情况下，我避免在开发中使用限制较少的权限，而不是在可公开的实时环境中所需的权限。这避免了在促进代码存活时意外地使perms过于宽松，并避免引入bug，在这些bug中，您的代码假定的访问权限比在活动环境中允许的要多。

Answer 3

对于PHP脚本来说，777权限通常被认为是个坏主意。如果这些文件是根用户拥有的，那么您很可能希望它们至少被apache组拥有，这样如果不是您想要的，它们就不必具有世界可读性。这样，您可以缩小到770权限。(从一开始，让root拥有这些脚本似乎有点奇怪。)

对于将来，您还可能希望在目录上设置粘性位，以确保添加到该目录的新文件自动被chgrp发送到拥有该目录的任何组，并使用以下命令：

chmod 2775 /path/to/目录

通过这种方式，您可以(例如)设置您为apache服务的目录的组所有者，并且添加的新内容将自动在apache组中，因此无需授予世界可读的权限(假设有一个适当的umask)。