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

时间:2012-03-05 02:43:20

标签: apache suphp

我正在尝试为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. 在docroot中
  2. 由user1拥有
  3. user1
  4. 无法修改

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

    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更改为{{1}}时,它又回到了suPHP错误。所以问题现在变成:当其中一个前台目录由其他人拥有时,如何让suPHP执行脚本?


    编辑:我现在意识到为什么Apache会抱怨。它无法进入

3 个答案:

答案 0 :(得分:1)

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

  

所有档案&目录必须由您的用户名拥有,而不是“没人”或其他名称/号码。如果它不归你所有,suPHP将拒绝运行该脚本并产生“内部服务器错误500”。

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

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

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

答案 1 :(得分: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可执行,所以如果它是一个脚本,那可能无效。这里的其他人也许可以确认。

答案 2 :(得分: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函数的教程。它们很容易实现。