只有读权限 可以正常执行文件 (是boolean用户在做这个读文件的操作吗？)
只有执行权限 提示拒绝 （是因为php本身就不是一个执行文件吗？ 还是因为是解释型语言？？）
同时有 读 执行 权限 报错
只有读权限 可以正常执行文件 (是boolean用户在做这个读文件的操作吗？)
只有执行权限 提示拒绝 （是因为php本身就不是一个执行文件吗？ 还是因为是解释型语言？？）
同时有 读 执行 权限 报错
操作系统对文件权限的管理，其复杂程度上远远超出我们的想象。经典的三位数字权限，根本就不是判断权限的可靠理由。举例：
ACL权限系统可以影响影响
mount命令的noexec等选项，可以干扰整个挂载点的权限
操作系统的权限机制，未来可能存在增补和扩充（这个其实才是最要命的）
我把话说得极端一点：“文件带不带RWX”就是方便给人看的，根本就构不成“是否有读/写/执行权限”的条件。
事实上对于用户程序来说，一个文件能否读/写/执行，根本就不能提前判定。我们编程时唯一的办法就是“试一试”——不做任何提前判断，直接把操作执行出去，出错了再说。
而此时如果判执行权限，那就非常危险了：php解释器尝试执行，如果成功了，那么执行此文件的行为就必然会发生，不可避免。这就意味着php解释器可以执行任何有执行权的文件，哪怕不是php代码也没关系。
这样在系统被黑，存在未知文件植入的情况下，我们就将失去php解释器的最后一层保护，黑客可以通过php解释器，任意执行任何语言编写的一切恶意程序。其后果将是毁灭性的。
所以“调用php命令来执行脚本时只需读取权限”，这个是当然的，也是必须的。
简而言之：任何语言的解释器，都只要求操作系统尝试读取代码文件，得到代码文本。解释器在得到代码文本之后，会自行负责后续的工作，无需操作系统染指。解释器和代码的关系，犹如编辑器和文稿文件的关系。解释器绝对不会委托操作系统去执行任意文件。
java也是这样的。一切解释型语言的解释器都是这样的，没有任何例外——过去没有，现在也没有，将来更不可能有。
问题出在你的执行方式上:
<code>#使用php的文件读取test.php文件内容执行; $ php -f test.php $ which php /usr/bin/php ./test.php #直接执行test.php文件</code>
两次进程主体并不一致;
shell执行一个解释型语言的脚本时, 会首先在文件头寻找shebang行, 按照shebang指定的解释器处理文件内容, 如果没有这一行则默认采用bash解释脚本;
<code>$cat x.php #!/usr/bin/php $./x.php #凡是具有x文件都可以这样直接调用, 并且按照shebang的解释器处理内容; hello #如果没有shebang的情况下, 则必须使用解释器(php)显式进行调用 $ php -f x.php # 有无shebang均无所谓, 只是把x.php文件内容读取出来传递给php解释器; 所以文件必须有r权限; hello $ </code>
