Apache不允许我输入属于其他用户的文件夹

Question

我正在尝试为 suPHP 设置 PHP 会话（请参阅 here）。我需要让用户拥有我的 php 验证文件，这样当 suPHP 启动时，它会为正确的用户执行此操作。但是，我也不希望用户有权访问该文件，o.w。他们可以对其进行编辑以仅返回 true 而不是实际检查数据库。

我的第一次尝试是这样的（Apache 以用户 www-data 运行）

/etc/validate
├── [drwx------ www-data  ]  user1
│   └── [-rwx------ user1  ]  validate.php
/var/www/
└── [drwx------ user1  ]  user1
    └── [-rwx------ user1  ]  index.html

然后让网页重定向到验证页面，验证页面将验证，然后返回/var/www/user1/index.html

RewriteCond %{REQUEST_URI} !^/xyz
RewriteRule ^(.*) /etc/validate/user1/validate.php?uri=$1

但是 suPHP 抱怨说我正在访问我的 docroot (/var/www/user1) 之外的东西。我不想将 docroot 设置为 / 并更新 suphp.conf 文件以使 check_vhost_docroot=false 无法修复（而且我不是要修复此问题）。因此，我只是将/etc/validate 移动到/var/www 中（我知道这有点乱）

/var/www/
└── [drwx------ user1  ]  user1
    ├── [-rwx------ user1  ]  index.html
    └── [dr-x------ www-data  ]  validate
        └── [-rwx------ user1  ]  validate.php

所以现在验证文件是

1. 在文档根目录中
2. 由用户 1 拥有
3. user1 不可编辑

但是现在如果我尝试加载页面，我会收到以下错误

Directory /var/www/user1/validate is not owned by user1

此时我正在失去耐心，所以我只是在其中粘贴了另一个虚拟文件夹，因此文件结构看起来像这样

/var/www/
└── [drwx------ user1  ]  user1
    ├── [-rwx------ user1  ]  index.html
    └── [dr-x------ www-data  ]  validate
        └── [drwx------ user1  ]  dummy
            └── [-rwx------ user1  ]  validate.php

现在，当我尝试加载页面时，Apache 告诉我“您无权访问此服务器上的 xyz。”其中xyz 是我的域名之后的任何内容。我不知道为什么 Apache 会告诉我，因为我 不 试图以文件/文件夹的形式访问尾随值。我认为，重定向失败了，Apache 只是假设它是失败的硬链接。

谁能告诉我我做错了什么或提供一种替代方法来阻止用户编辑他们的文件。它无法进入目录dummy，因为它的权限是rwx------，只有user1 可以cd 进入它。当我将权限从0700 更改为0755 时，它又回到了suPHP 错误。所以现在的问题变成了：当 suPHP 的一个后台目录被其他人拥有时，我如何让 suPHP 执行脚本？

---

编辑：我现在明白为什么 Apache 抱怨了。进不去

Answer 1

我找不到任何官方链接，但根据this网站：

所有文件和目录必须归您的用户名所有，而不是“nobody”或其他名称/号码。如果它不属于您，suPHP 将拒绝运行该脚本并产生“Internal Server Error 500”。

我可以理解文件，但我认为不需要属于您的目录。我在网上找到了一个补丁（见here），但是我不知道它是否有效，因为我还没有测试过。

编辑：有一种方法可以让用户在他们的 docroot 之外访问脚本（通过suPHP_GlobalDocRoot）。我无法让它为我工作，Apache 声称这是一个语法错误。无论如何，即使它确实有效，它仍然需要至少对所有目录执行访问0111（并且可能还读取0555）一直到/。

因此，我非常有信心绝对没有解决我的问题。我因此接受这个作为答案。如果有人设法提供一个答案，我会选择另一个答案。

Answer 2

我可能是错的，但如果 suPHP 以我记忆中的方式工作，那么 PHP 在用户（在本例中为 user1）下运行，而不是在 Apache（www-data）下运行，在这种情况下，www-data）是唯一的具有对验证文件的读写访问权限，并且 user1 不是 www-data。

我认为，解决方案是向所有人授予读取权限，以仅对 www-data 进行验证和写入权限。所以：

/var/www/
└── [drwx------ user1  ]  user1
    ├── [-rwx------ user1  ]  index.html
    └── [dr-x---r-- www-data  ]  validate
        └── [-rwx------ user1  ]  validate.php

通过上述，user1 不能编辑他们的验证文件，只能读取它。

您可能还想尝试：

/var/www/
└── [drwx------ user1  ]  user1
    ├── [-rwx------ user1  ]  index.html
    └── [dr-x-----x www-data  ]  validate
        └── [-rwx------ user1  ]  validate.php

我总是对“执行”的工作原理感到困惑，但我相信这个想法是文件可以由用户运行（执行），但不能读取或写入。但这需要validate 是可执行的，所以如果它是一个脚本，那可能不起作用。这里的其他人可能能够确认。

Answer 3

suPHP 有很多配置选项，没有它们我无法给出确切的答案，所以我假设您正在运行一个漂亮的 std 配置，因为如果你没有设置它严格来说，你引入了这么多可利用的漏洞，使用它没有多大意义。

• PHP 脚本必须归非特权 UID 所有
• 返回到 / 的路径必须由相同的 UID 或 root 拥有。
• 如果脚本或任何父目录不能被其他用户 UID 写入。
• 脚本在用户 UID 中执行。

这是 suPHP 正式保证模型的一部分，如果您想更改它，请不要使用 suPHP。

用户可以定义自己的路径来加载 PHP.ini。默认情况下，用户可以指定自定义 php.ini 和 IIRC，您不能禁用 suPHP_ConfigPath 选项。毕竟，您在用户 UID 中运行 php-cgi。所以这意味着即使你建立了一个auto_prepend_file（它可以由root拥有并且不能被UID写入），那么有知识的用户仍然可以绕过这个。

我的简单问题是你为什么使用 PHP，或者至少是 suPHP 建立的 PHP 处理程序来完成你想要在这里实现的目标？为用户和用户特权函数保留 PHP。使用 CGI 脚本甚至是 RewriteMap 和 prg: 这些“系统”函数的选项。如果这是您的首选语言，您甚至可以在 PHP 中轻松实现它，因为这将使用 php-cli 执行。有很多关于如何编写 Map prg 函数的教程。它们很容易实现。