我和一所大学的系统pipe理部门一起工作，偶然发现了一些可能很常见的事情，但对我来说却是相当震惊的。
所有public_html目录和web区域都存储在afs上，并具有对web服务器的读取权限。 由于用户可以在其public_html中使用php脚本，这意味着他们可以从php（和主要web文件！）中访问彼此的文件。
这不仅使得.htaccess的密码保护function完全无用，而且还允许用户阅读包含mysql数据库密码和类似敏感信息的php源文件。 或者如果他们发现其他人拥有Web服务器具有写访问权限的目录（例如，用于个人日志或保存提交的表单数据），则他们可以将文件存储在这些帐户中。
一个简单的例子：
<? header("Content-type: text/plain"); print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); ?> 这是常见的问题吗？ 你通常如何解决它？
更新：
感谢您的input。 不幸的是，似乎没有简单的答案。 在这样一个大的共享环境下，用户可能不应该有这么多的select。 我能想到的最好的方法是在所有“public_html”目录的主要configuration中设置“open_basedir”，运行suphp并且只允许清洁php（没有cgi脚本，用反引号等运行外部命令）。
改变这样的政策虽然会破坏很多东西，但很可能会让用户抓住他们的干预并追逐我们……我将与我的同事们讨论，如果我们决定如何更改设置，请在此更新。
可以使用suphp来运行php脚本和其所有者的uid。
我的build议是限制PHP访问文件（通过open_basedir和类似的指令，每个虚拟主机的基础上）：你希望用户能够打开/读/写文件在他们的webroot，也许一个级别以上（用于暂存空间），但不是他们将存储的目录，例如htpasswd文件。
目录结构如下所示：
/Client /auth /site /www_root /www_tmp
满足这个要求： open_basedir可以安全地指向/Client/site ，而htpasswd文件存储在/Client/auth （用.htaccess文件或httpd.conf修改为指向相应的位置）。
这可以防止你的客户打开其他人的文件，并且作为一个好处，恶意用户不能读取/Client/auth （或者你的系统上的其他东西，比如/etc/passwd 🙂
请参阅http://php.net/manual/en/ini.core.php了解更多关于open_basedir和per-vhost实现的细节。
不，这不是一个常见的问题，因为大多数共享主机会在每个用户的public_html目录中的htaccess文件中定义一个open_basedirconfiguration（如果每个用户都有自己的vhost，则在vhost中）。
例如.htaccess文件：
# Assuming these are not set globally - its good practice to limit: php_flag magic_quotes_gpc off php_flag magic_quotes_runtime off php_flag register_globals off php_flag short_open_tag off php_value max_execution_time 60 # These set the user-specific paths php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include php_value session.save_path /afs/example.com/home/smith/tmp php_value upload_tmp_dir /afs/example.com/home/smith/tmp
但是确保你在.htaccess文件上设置了正确的权限，以防止用户改变open_basedir（如果他们试图在subdir / .htaccess中覆盖它，它不应该工作 – 但你应该testing这个以确保） 。
HTH
C。
AFS忽略简单的unix用户权限。 suPHP在运行php程序之前执行一个setuid，但是这并没有为进程提供访问AFS所需的kerberos令牌，并限制了它的权限。 suPHP必须以某种方式进行修改才能获得这些令牌，然后才能以该用户的身份将自己呈现给AFS系统。 据我所知，这还没有完成。 （事实上，当我看看是否有人这样做的时候，我发现了这个问题。）