我正在使用suexec来确保PHP脚本（以及其他CGI / FastCGI应用程序）作为与相关虚拟主机关联的帐户持有者运行。 这允许保护每个用户的脚本不被其他用户读/写。
但是，我发现这样做会带来不同的安全漏洞。 以前，Web服务器作为非特权用户运行，对用户文件具有只读权限（除非用户由于某种原因更改了文件权限）。 现在，Web服务器也可以写入用户的文件。
因此，虽然我阻止了不同的用户利用对方的脚本，但是我已经做到这样，如果某些应用程序存在远程代码注入漏洞，现在它不仅具有读取权限，而且还具有对所有用户脚本和网站。
我该如何处理？
我有一个想法是为系统中的每个用户帐户创build第二个用户帐户，以便每个用户都有自己的用户帐户，并且他们的所有脚本都在另一个用户帐户下运行。 但是这似乎很麻烦。
在Web服务器的权限下运行PHP并不一定比使用SuPHP 更好或更差 。 这是不一样的 。 第一个模型将所有者与Web服务器分开，而第二个模型将所有者（和他的PHP代码）与机器上的所有其他用户分开。
使用suPHP不一定会提高您的整体安全性，只是redirect它。 而不是试图防止闯入，你是孤立的彼此的网站。 理由是，特别是在一个共享主机的环境中，以前的安全模式只是没有解决：用户不断地在安全性上吹嘘漏洞，通过设置全局写权限来让Web应用程序工作，然后在一个账户上的安全妥协将迅速转移到服务器上的所有其他账户。
所以，现在通常在大型共享主机环境中使用像suPHP这样的工具来消除用户和他的PHP应用程序之间的障碍，而是在用户和他的邻居之间架起一道屏障。
所以，在这种情况下，你不提供安全性 ，你提供分离 。 不幸的是，suPHP要求文件由您打算运行的用户拥有 ，所以创build一个单独的FTP用户将是一团糟。 您将不断需要在suPHP用户和FTP用户之间来回传送文件。
相反，您需要select一个angular色：要么保护站点，要么保护服务器。 如果要保护网站，则需要将networking服务器与内容所有者分开。 这是一个有点复杂的关系来维护正确，所以不build议共享主机环境。 相反，如果您想要保护服务器免受其用户的侵害，则使用suPHP将用户（和他的代码）与服务器上的其他用户分开。 在这种情况下，用户对自己的安全负责。 祝你好运，用户！ 从技术上讲，至less在理论上可以有一个安全的PHP应用程序。
首先，如果一个文件的所有者不需要写入权限，不要给他们。 您可以通过设置UNIX权限的第一个数字来完成此操作。 这意味着只有root用户才能对其文件进行写入访问。 这将是非常恼人的时候，他们将需要升级文件，但你已经表示，他们不应该有写访问….
其次，他们作为一个特定的用户执行脚本。 如果使用open_basedir将它们locking在一个文件中，那么如果它们可以写入文件就不会有问题。 如果有黑客攻击，它将只销毁该用户的文件。 即使没有open_basedir，他们也应该只能写在他们的文件，除非你有777权利这是另一个问题的文件。
第三，许多网站至less需要写访问某些文件/文件夹。 每个例子，Wordpress需要写入，以防上传文件。 如果你pipe理得好，写访问网站不一定是一个安全漏洞。
suexec是一个非常好的开始，open_basedir将确保具有写入权限的用户保留在定义的目录中。
suexec总是让我感到非常恼火，因为你处在一个固有的共享主机环境中 – 允许不可信的请求调用一个脚本，因为拥有的用户非常糟糕（以及WordPress如何安装） – 如果你是在专用的主机上，毕竟你不会把所有的文件都设置为模式0777。 只是删除写访问将无济于事，因为这些文件仍然由该用户拥有 ，因此最终是可写的。 有两个单独的用户也没有太大的帮助，出于同样的原因。
在我看来，正确的解决scheme是将脚本作为非特权用户运行，但是将它们chroot – 可能FastCGI在这里是一个很好的解决scheme… fcgi进程是chroot，但是web服务器知道在哪里find它创build的套接字。
我意识到这不是一个“答案”，但我会把钱放在一个曾经提出过这个可能实现它的人 – 也许甚至作为suexec本身的补丁（我会设想ForceSUExecUID和ForceSUExecGID选项，可能是在每个虚拟主机的基础上应用…）