操作系统对文件权限的管理，其复杂程度上远远超出我们的想象。经典的三位数字权限，根本就不是判断权限的可靠理由。举例：

• ACL权限系统可以影响影响

• mount命令的noexec等选项，可以干扰整个挂载点的权限

• 操作系统的权限机制，未来可能存在增补和扩充（这个其实才是最要命的）

我把话说得极端一点：“文件带不带RWX”就是方便给人看的，根本就构不成“是否有读/写/执行权限”的条件。

事实上对于用户程序来说，一个文件能否读/写/执行，根本就不能提前判定。我们编程时唯一的办法就是“试一试”——不做任何提前判断，直接把操作执行出去，出错了再说。

而此时如果判执行权限，那就非常危险了：php解释器尝试执行，如果成功了，那么执行此文件的行为就必然会发生，不可避免。这就意味着php解释器可以执行任何有执行权的文件，哪怕不是php代码也没关系。

这样在系统被黑，存在未知文件植入的情况下，我们就将失去php解释器的最后一层保护，黑客可以通过php解释器，任意执行任何语言编写的一切恶意程序。其后果将是毁灭性的。

所以“调用php命令来执行脚本时只需读取权限”，这个是当然的，也是必须的。

简而言之：任何语言的解释器，都只要求操作系统尝试读取代码文件，得到代码文本。解释器在得到代码文本之后，会自行负责后续的工作，无需操作系统染指。解释器和代码的关系，犹如编辑器和文稿文件的关系。解释器绝对不会委托操作系统去执行任意文件。

java也是这样的。一切解释型语言的解释器都是这样的，没有任何例外——过去没有，现在也没有，将来更不可能有。

问题出在你的执行方式上:

#使用php的文件读取test.php文件内容执行;
$ php -f test.php
$ which php
/usr/bin/php

./test.php #直接执行test.php文件

两次进程主体并不一致;

shell执行一个解释型语言的脚本时, 会首先在文件头寻找shebang行, 按照shebang指定的解释器处理文件内容, 如果没有这一行则默认采用bash解释脚本;

$cat x.php 
#!/usr/bin/php <-这一行就是shebang
<?php
echo "hello"
?>

$./x.php  #凡是具有x文件都可以这样直接调用, 并且按照shebang的解释器处理内容;
hello

#如果没有shebang的情况下, 则必须使用解释器(php)显式进行调用
$ php -f x.php # 有无shebang均无所谓, 只是把x.php文件内容读取出来传递给php解释器; 所以文件必须有r权限;
hello
$