PHP 正在列出具有可读权限的文件，但不能 file_get_contents 或 require_once

Question

这是一个 Drupal 站点，其中 includes/module.inc 对注册表中的文件运行循环并尝试 require_once()。对于许多文件，即使文件权限正确且文件应该可读，这也是失败的。

我已将调试代码添加到循环输出以检查文件权限和内容：

  // Debug code
  print "$file perms:" . substr(sprintf('%o', fileperms($file)), -4) . "<br>";
  print "$file contents:<br>" . htmlspecialchars(file_get_contents($file)) . "<hr>";

  // Original Code
  require_once $file;

在尝试 require_once 之前，它会输出文件权限以及文件内容。不同的页面在不同的文件上失败，例如主页正在输出：

./sites/default/modules/cck/includes/content.token.inc perms:0755
./sites/default/modules/cck/includes/content.token.inc contents:

[filecontent]

./sites/default/modules/filefield/filefield.token.inc perms:0644
./sites/default/modules/filefield/filefield.token.inc contents:

[filecontent]

./sites/default/modules/getid3/getid3.install perms:0644
./sites/default/modules/getid3/getid3.install contents:

[NO FILE CONTENT]

因此，出于某种原因，./sites/default/modules/getid3/getid3.install 据称拥有可读权限，但事实并非如此。

不同的路径显示不同的文件存在问题：

/
    ./sites/default/modules/getid3/getid3.install perms:0644
/admin
    ./sites/default/modules/webform/components/date.inc perms:0644
/user
    ./sites/default/modules/cck/includes/content.crud.inc perms:0755

编辑：

请注意上面./sites/default/modules/cck/includes/content.token.inc 可读但./sites/default/modules/cck/includes/content.crud.inc 给出错误，这是这些文件的目录列表（包括--context 以检查SELinux）

# ll --context
total 168
drwxr-xr-x 4 root root ?  4096 Sep 28 05:50 ./
drwxr-xr-x 8 root root ?  4096 Nov  6  2013 ../
-rwxr-xr-x 1 root root ? 72264 Nov  6  2013 content.admin.inc*
-rwxr-xr-x 1 root root ? 26307 Sep 28 03:13 content.crud.inc*
-rwxr-xr-x 1 root root ?  7181 Nov  6  2013 content.devel.inc*
-rwxr-xr-x 1 root root ?  3868 Nov  6  2013 content.diff.inc*
-rwxr-xr-x 1 root root ? 15914 Nov  6  2013 content.node_form.inc*
-rwxr-xr-x 1 root root ? 12550 Nov  6  2013 content.rules.inc*
-rwxr-xr-x 1 root root ?  6246 Nov  6  2013 content.token.inc*
drwxr-xr-x 3 root root ?  4096 Nov  6  2013 panels/
drwxr-xr-x 3 root root ?  4096 Nov  6  2013 views/

crud的修改日期是我在错误发生后评论代码进行测试，但现在又恢复了。

编辑 2：

似乎也禁止尝试直接访问robots.txt。不确定这是否是同一个问题，但文件看起来应该是完全可读的。

# ll robots.txt 
-rw-r--r-- 1 6226 6226 1521 Aug  6 18:07 robots.txt 

编辑 3：

看起来问题出在 AppArmor 上，我认为它类似于 SELinux。从aa-enforce 更改为aa-complain 解决了这个问题。

Answer 1

也许一些 selinux cmd 之类的可能会运行它：

semanage fcontext -a -t httpd_httpd_sys_content_t '/var/lib/myapp(/.*)?'
restorecon -R -v /var/lib/myapp

/var/lib/myapp 是你的 ./ 目录

Answer 2

看起来问题出在 AppArmor 上，我认为它类似于 SELinux。从aa-enforce 更改为aa-complain 解决了这个问题。