当日志的配置从默认的 single 改为 daily 之后,生成的日志的所属变成 PHP-fpm 的用户和组了,会导致实际系统用户在执行 migrate 时没有权限。

total 1092
drwxrwxrwx 2 kiyoma kiyoma    4096 4月  25 09:47 ./
drwxrwxrwx 6 kiyoma kiyoma    4096 4月   2 09:14 ../
-rw-rw-r-- 1 kiyoma kiyoma      14 3月  25 16:09 .gitignore
-rw-r--r-- 1 php73  www        137 4月  24 17:16 laravel-2019-04-24.log
-rw-r--r-- 1 php73  www      43010 4月  25 10:37 laravel-2019-04-25.log
-rwxrwxrwx 1 kiyoma kiyoma 1044673 4月  23 20:41 laravel.log*

最底下的laravel.log是原本默认的single模式下的日志文件。
但是自从把配置修改为daily后,日志文件的所属就变了。
原本我还没发现这一点,知道今天改了表结构,要跑migrate的时候,提示

"laravel-2019-04-25.log" could not be opened: failed to open stream: Permission denied

我才查出了这个问题。

我想,在正常的生产环境部署下,访问终端的管理员用户,和运行php-fpm的用户,肯定不会是同一个吧?那应该如何解决这个问题呢?

《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
最佳答案

@kiyoma 比如我们给 PHP-fpm 的用户是 www,在 /etc/passwd 中是这样的

www:x:99:99::/:/sbin/nologin

这个用户是不能登录 shell 的,
然后添加一个新用户同时指定用户ID 和用户组

useradd -u 99 -g 99 -o nobody
#修改密码
passwd nobody

/etc/passwd 就多了一条记录

www:x:99:99::/:/sbin/nologin
nobody:x:99:99::/home/nobody:/bin/bash

这样我们在终端中用 su 切换 nobody 用户上执行命令,就没有权限问题了

su nobody

你会发现 nobody 用户创建文件或执行的命令都是显示 www 用户的。
别忘了给项目赋予同样的用户所属者和所属组

4年前 评论
讨论数量: 12

我们一般部署上线时,为了安全,会给 nginx 和 PHP-fpm 分配一个低权限,无 shell 登录的用户执行,同时为这个用户建立一个可登录 shell 的替身账号来方便执行跟项目相关的命令,这样是有点麻烦,但是能避免很多问题。同时也不建议给 storage 下面的目录分配 0777 权限。

祝你好运 :wink:

4年前 评论

@kiyoma 比如我们给 PHP-fpm 的用户是 www,在 /etc/passwd 中是这样的

www:x:99:99::/:/sbin/nologin

这个用户是不能登录 shell 的,
然后添加一个新用户同时指定用户ID 和用户组

useradd -u 99 -g 99 -o nobody
#修改密码
passwd nobody

/etc/passwd 就多了一条记录

www:x:99:99::/:/sbin/nologin
nobody:x:99:99::/home/nobody:/bin/bash

这样我们在终端中用 su 切换 nobody 用户上执行命令,就没有权限问题了

su nobody

你会发现 nobody 用户创建文件或执行的命令都是显示 www 用户的。
别忘了给项目赋予同样的用户所属者和所属组

4年前 评论

这是因为你开始设置过 storage 目录的权限和所属用户,分组,目录下都是 777。所以使用系统命令是没有影响的。但是改为daily之后就log文件是php所属的用户分组 生成的,所以权限和用户分组和之前的都不同了。可以在执行命令的时候切换用户

4年前 评论

我们一般部署上线时,为了安全,会给 nginx 和 PHP-fpm 分配一个低权限,无 shell 登录的用户执行,同时为这个用户建立一个可登录 shell 的替身账号来方便执行跟项目相关的命令,这样是有点麻烦,但是能避免很多问题。同时也不建议给 storage 下面的目录分配 0777 权限。

祝你好运 :wink:

4年前 评论

@maxlcoder 这些原因我都想到了,只是觉得这些情况都是客观存在的,且几乎是必然的(运维用户和php用户绝对不可能是同一个),那也就客观导致了这个问题的出现。所以有些想不通,是谁的责任,laravel没设计好吗?最佳解决方案是什么?
我尝试过用su -php用户 -c "XXXXX" 去执行migrate,然而这个php用户是没有密码的,不知道密码该输入什么。
最后我解决的方法是——如果我现在要跑migrate,就sudo chmod 666 今天的日志文件。。。。。。。

4年前 评论

@ivothgle 我感觉这就是我要的答案了,只是【可登录 shell 的替身账号】这个概念不理解,大佬能否详解下?

4年前 评论

@kiyoma 比如我们给 PHP-fpm 的用户是 www,在 /etc/passwd 中是这样的

www:x:99:99::/:/sbin/nologin

这个用户是不能登录 shell 的,
然后添加一个新用户同时指定用户ID 和用户组

useradd -u 99 -g 99 -o nobody
#修改密码
passwd nobody

/etc/passwd 就多了一条记录

www:x:99:99::/:/sbin/nologin
nobody:x:99:99::/home/nobody:/bin/bash

这样我们在终端中用 su 切换 nobody 用户上执行命令,就没有权限问题了

su nobody

你会发现 nobody 用户创建文件或执行的命令都是显示 www 用户的。
别忘了给项目赋予同样的用户所属者和所属组

4年前 评论

@ivothgle NB,我感觉我要再翻翻《鸟哥Linux》关于用户和组的那块内容,才能消化这段了。
多谢大佬 :kissing_heart:

4年前 评论

@ivothgle

这样我们在终端中用 su 切换 www 用户上执行命令,就没有权限问题了

这里是不是说错了?su到nobody上吧?

4年前 评论

@kiyoma 我改一下吧,谢谢提醒

4年前 评论

直接 sudo -u www-data php artisan ... 即可... 用 su 的话,所有运维人员都需要知道目标用户的密码。

4年前 评论

我觉得更简单的做法是分离 http 日记和 console 日志,让两个独立互不影响,完全不用关心系统权限问题,而且查看起来也更清晰。

https://tiicle.com/items/95/laravel-lumen-...

4年前 评论

@Vanry 有点好奇,你两年前写这篇文章的时候,是不是也是遇到了我这个问题

4年前 评论
lawyi

file
我一般这么处理。。

4年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!