我正在考虑使用 suphp。似乎 php 中新创建的文件拥有 apache.apache 的所有权，这可能会成为一个问题。此外，似乎使用 suphp 更容易监控 php 脚本发送的垃圾邮件和负载使用情况。
但是我担心这会降低服务器的性能。我使用 Plesk 和 DirectAdmin 控制面板作为服务器，每个服务器托管大约 200 个域，但我不想看到 suphp 的负载大幅增加。另外，我不确定 suphp 是否只是通过 cgi 的 php 的别称。
苏php
- 慢了将近10倍？
- 这只是 CGI 下的 php？我们 10 年前就是这样做的吗？
- 更容易监控，所有脚本都在用户名下运行。
- 最低权限 = 640。
mod_php
- 快多了
- 与 apache 更好地集成？
- 脚本在 apache:apache 下运行。
- 最低权限 = 64 4（！），读取密码文件仅受 open_basedir 限制，而不是实际的 linux 默认权限系统？
那么... suphp 是否提供了更高的安全性？它在监控威胁（垃圾邮件）、基准测试（php 脚本激增）等方面是否提供了很大的好处？性能损失有多大？
答案1
suphp 与 PHP 不同，它们之间存在许多功能差异。
运行标准 CGI 接口比运行 fastCGI / webserver 模块要慢得多。据我所知，suphp 不支持 fastCGI - 但现在有一个 apache 模块版本。它确实提供了一些标准 PHP 所没有的安全调整，但后者在这方面并不差。最重要的问题是您是否愿意从 tarball 维护软件，以及您的用户是否会对功能落后于官方版本的 PHP 版本感到满意。
无论你选择哪个版本，它都只能提供你配置的安全性。如果你决定使用标准 PHP，那么请确保：
1）你设置 open_basedir 来限制用户进入他们自己的目录
2）您可能需要禁用 allow_url_fopen
3）你一定要禁用 allow-url-include
4）如果你想要一个非常严格的系统，那么禁用 eval 和 create_function
5）设置每个用户的include_path
6）更改 sendmail_path 以指向一个包装脚本，该脚本记录正在使用的帐户（您应该能够从 cwd 中解决这个问题）并实现配额
7）将 session.save_path 设置为每个用户的位置
我不知道 suphp 中是否有专门解决垃圾邮件问题的内容 - 但您可以像上面所述那样轻松添加自己的包装器脚本。请注意，上面的大多数步骤也适用于 suphp - 它只是使在配置文件指令中放入参数变得更容易，而不是在 apache 配置或通过 .htaccess 覆盖它们。
答案2
我建议使用信息技术有限公司相反。您必须为每个用户运行单独的 VirtualHost，但您可能无论如何都会这样做。但是，如果您正在运行 mod_userdir，那么您就没那么幸运了，必须使用 suphp 才能获得正确的分离。