理清PHP在Linxu下执行时的文件权限

首先推荐一个linux权限的视频：Linux权限管理之基本权限，讲的非常好，看完后就基本明白了。

一、文件权限及所属

1、文件有三种类型的权限，为了方便期间，可以用数字来代替，这样可以通过数字的加减，用一个数字就能标识这个文件的权限了，例如7=4+2+1，表示读写执行3个权限都有，6=4+2，表示有读写权限没有执行权限等等

2、联想web应用的rbac权限管理等，linux下同样有用户权限的管理，用户有用户名和用户组，一般创建用户时同时会创建同名的用户所属组。

先root账号登录随便新建一个目录和一个文件

查看时会发现：

先看上方蓝色的部分，第一位为标识符，去掉第一位，后面每三位分隔，以abc文件夹为例:d | rwx | r-x | r-x

所以abc文件夹中表示owner拥有rwx（7），group拥有rx（5），other拥有rx（5）。

同样上方文件中红色的部分，依次为所有者的名称和所属组的名称，也就是abc文件夹的所有者为root，所属组为root。此时：

a、如果是root用户来访问这个abc文件夹，相当与owner，拥有7的权限

b、如果一个新的用户名test用户组为root来访问abc文件夹，则相当于group，拥有5的权限

c、如果一个新的用户名test用户组为test的来访问abc文件夹，则相当与other，拥有5的权限

二、文件各权限的作用

本来还想边测试边说，但是太麻烦了，直接说结果吧。可以自己新建一个用户，然后修改权限来自己测试下。

1、目录

a、进入目录，即cd命令，所需要的权限为执行权限（x）

b、查看目录内的文件，即ls命令，需要的权限为读取权限（r）

c、创建删除目录内的文件夹/文件，即mkdir/touch命名，需要的权限为写如权限（w）

顺便说下目录只影响下一级的，隔代不影响，好比一个目录abc/sub/，如果abc没有w权限，但sub有w权限，则可以在sub中创建文件，当然abc也需要有x权限，否则都进不去更不用说创建了，但只要能进去（可以通过切换root管理员的方法），就不会再受abc的影响，只会受sub的影响。

一般我们目录会给5（rx）的权限，也就是读取和执行权限，只有图片上传或缓存等目录需要创建的才会给7（rwx）的权限

2、文件

a、文件打开，可以用cat/vim命令打开，所需权限为读取权限（r）

b、文件修改，可以用cat/vim命令打开并保存，所需权限为写入权限（w）

c、文件执行，可以直接./abc.out等执行，所需要权限为执行权限（x）

这里需要说明的的是php无论是命令行执行（类似运行 php abc.php）还是web端执行，名为执行，实际上是读取文件到php内核中取解析，所以只要有读取权限（r）就可以，同样例如abc.sh，如果直接运行./abc.sh需要的是执行权限（x），但是运行 sh abc.sh 命令需要的是读取权限（r）。

一般我们文件会给4（r）权限，也就是读取权限，只有日志、缓存等需要向文件中写入内容的才会给6（rx）权限

之所以上方没有说755，777、644权限，而仅仅是是说单个的权限，是因为你的网站目录所属的权限不能确保与执行时所用的用户什么关系，也就是说执行时的用户可能是owner、可能是group也可能是other

三、php执行时的权限

我们自己在ssh连接linux操作时必须要有个用户名才能登录操作，同样php要想处理php相关的文件，也是在某个用户下操作的，而用户是在哪里创建或定义的呢，一般会是在安装php环境时创建的，例如apache，nginx等环境都会默认创建用户和用户组，而php的读取时就用此用户来读取，可以通过查看配置文件来确认：

或者是通过命令查看进程：

以apache为例会显示：

第一列就是显示的哪个用户在执行它，主要看非root下的。上方说明是www用户在运行apache进程来处理php文件。一般来说apache/nginx会以root来启动主线程，然后fork出子线程来处理具体的业务，而子进程在创建时会根据配置文件中的用户名和用户组通过setuid和setgid命令来设置有效用户名和有效用户组。需要注意的是“有效”这两个字，例如，某个用户名为test，其所属组test，而apache中配置文件中设置的用户名为test，但是用户组设置为abc，这时就可能很疑惑了，那组到底是按照用户名所属的组还是配置文件中设置的组呢？答案是设置的，因为通过setgid变更了，具体谷歌百度搜索“有效用户”、“实际用户”、“setuid函数”等关键字。

这里需要注意的是，如果有安装php-pfm，则应该还需要查看php-pfm执行时的用户名及用户组。（php-pfm的用户最好和nginx一致）

默认的可能是nobody或者apache等其它的用户及用户组，上方是已修改过的。此时应该在网站目录中用ls-all来确认下网站文件是属于哪个用户，分几种情况说明下吧：

a、例如网站所有者是这样：

网站所有者为www，而php执行者也为www，那说明是具有owner权限，上方system文件夹中755中的55根本不起作用，只要是7xx就会以7（rwx）的权限来执行。

b、如果网站所有者是这样：

网站所有者为test，所属组为www，而php执行者为www，执行组为www，那说明是说在同一组中，具有group权限，上方system文件夹中755中的7和5不起作用，只要是x5x就会以5（rx）的权限来执行。

c、如果网站所有者是这样：

网站所有者为test，所属组为test，而php执行者为www，执行组为www，那说明是说根本没什么关系，具有other权限，上方system文件夹中755中的75不起作用，只要是xx5就会以5（rx）的权限来执行。

所以不能简单的说修改权限为755，644什么的，还需要确认程序的执行者和网站的所有者才能确定权限。

目前好多集成环境为了省事（嗯，lanmp、lnmp等），将php的执行权限和网站所在目录都设置为www，此时一般创建完目录后为755，创建文件后为644，当php执行时，起作用的目录权限为7（所有目录拥有创建删除权限）和文件权限6（所有文件具有写权限），这种是不是挺不安全的？正常应该是目录为5，文件为4，当有特殊需求时才将权限设为7。如果出现上方说的这种情况，修改的方法一是修改apache/nginx的用户和用户组，二是修改网站文件的所有者和所有组这两个方向来修改（推荐比较简单），以确保网站的安全。

以上，只是基础的权限说明。

---

2018.07.08补充：

补充下php在cli模式下的运行，一开始以为命令行`php xxx.php`这种命名是以PHP用户来运行，但实际上不是的，而是以当前用户来执行，类似在xxx.php文件中通过mkdir创建一个文件夹，生成的文件夹所属用户和组并不是php的www用户，而是当前身份的root用户。所以当涉及到通过cli命令来创建文件等时，需要修改到php的用户来执行，类似 `sudo -u www php xxx.php`，同样如果用到计划任务，在crontab中，也需要指定php的www用户来执行，否则就会创建出所属root用户的文件，然后如果普通的web操作还修改此文件，很容易会出现权限不足的情况。