1

我正在尝试为 suPHP 设置 PHP 会话（请参见此处）。我需要让用户拥有我的 php 验证文件，这样当 suPHP 启动时，它会为正确的用户执行此操作。但是，我也不希望用户访问该文件，因为他们可以编辑它以仅返回 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. 在 docroot 内
  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 抱怨了。进不去

4

3 回答 3

1

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

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

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

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

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

于 2012-03-05T03:38:13.767 回答
0

suPHP 有很多配置选项，没有它们我无法给出准确的答案，所以我假设您正在运行一个非常标准的配置，因为如果您没有非常严格地设置它，那么您引入了这么多可利用的漏洞，以至于使用它没有多大意义。

  • 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 函数的教程。它们很容易实现。

于 2012-03-06T00:17:37.177 回答
0

我可能是错的，但如果 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是可执行的，所以如果它是一个脚本，那可能行不通。这里的其他人可能能够确认。

于 2012-03-05T03:00:08.723 回答