这里有点长远,但我想看看是否有人可以解决这个问题:
我遇到了一个问题,即 PHP 函数 unlink() 能够成功删除文件,即使已对相关文件应用了显式拒绝 NTFS 权限。我甚至尝试过删除所有 NTFS 文件权限等 - 结果相同,这让我很困惑。
事实
我在 Windows Server 2008 R2 上安装了 Apache 2.2.22,运行 PHP 5.4.5
Apache/PHP 正在用户 EXODUS\wwwuser 下运行,运行 PHP 脚本时对命令行中的‘whoami’的响应可以证明这一点 - 例如:
echo exec('whoami');
返回
EXODUS\wwwuser
文件“deleteme.txt”由“BUILTIN\Administrators”组的成员创建,明确拒绝对 EXODUS\wwwuser 的文件应用权限 - 但是,PHP 的 unlink() 函数成功删除了该文件。
我尝试了同样的事情,删除此文件的权限继承,删除所有权限(包括 SYSTEM),并对 EXODUS\wwwuser 应用明确拒绝“完全控制” - 猜猜怎么着,unlink() 仍然会删除该文件......
EXODUS\wwwuser 是 BUILTIN\Users 的成员,但这并不表示这会影响情况。
当以交互方式登录时,EXODUS\wwwuser 无法删除文件。
当文件由 PHP 写入时,文件所有者为 'EXODUS\wwwuser'
有人对此有什么想法吗?
我该如何提供位于定义的“open_basedir”区域内的无法通过 PHP 的 unlink() 删除的文件夹/文件?
我正在使用“open_basedir”来阻止脚本篡改声明的open_basedir之外的文件 - 这似乎运行良好 - 例如:无法删除“open_basedir”定义的位置之外的文件。
答案1
您好,如果 PHP 能够删除文件,即使权限另有规定。这可能意味着 Apache 以具有管理员权限的用户身份运行。
如果上述问题不存在,您可以随时尝试审核 Windows 中的文件夹,以确保所有子文件夹权限都已重置。
答案2
我没有在 Windows 上使用 PHP,因此无法确定它的底层代码,但当我编写任何形式的删除函数时,我让它做的第一件事就是尝试删除现有权限。也许它unlink()
正在做同样的事情。如果您启用了适当的日志记录,您应该能够在 Windows 事件日志中看到任何此类行为,因此请在那里检查。
答案3
唯一可能的情况是,Apache 服务器实际上没有在您所说的用户下运行。打开该文件夹的审核并再次测试以查看哪个用户正在删除该文件。
另外,该文件的所有者是谁?