PHP 脚本需写入日志、缓存 → 必须对目录有 写权限的庖丁解牛

“PHP 脚本需写入日志、缓存 → 必须对目录有写权限”，这不仅是 Linux 权限模型的基本要求，更是Web 应用稳定运行的生死线。一旦权限缺失，轻则功能异常（500 错误），重则安全漏洞（权限过度开放）。

一、核心原理：为什么必须有写权限？

▶ 1.PHP 进程的运行身份

• 典型架构：
  • Web 服务器（Nginx/Apache）接收请求
  • PHP-FPM 以特定用户身份执行脚本（如deploy）
• 关键事实：

  PHP 脚本的文件操作权限 = PHP-FPM 进程的用户权限

▶ 2.Linux 文件权限模型

• 写权限（w）含义：
  • 对文件：可修改内容
  • 对目录：可创建/删除/重命名子文件
• 权限检查流程：

💡核心认知：
目录写权限 ≠ 文件写权限 —— 目录写权限决定能否创建/删除文件

二、典型场景与错误表现

▶ 场景 1：Laravel 日志写入失败

• 现象：

  PHP Warning: fopen(/www/storage/logs/laravel.log): failed to open stream: Permission denied

• 原因：
  • /www/storage/logs目录属主为root
  • PHP-FPM 以deploy用户运行 → 无写权限

▶ 场景 2：缓存生成失败

• 现象：
  • 页面空白或 500 错误
  • 日志：file_put_contents(/bootstrap/cache/config.php): Permission denied
• 原因：
  • 缓存目录未授权给 PHP 用户

▶ 场景 3：Session 存储失败

• 现象：
  • 用户无法登录（Session 无法写入）
  • 日志：Failed to write session data (files)
• 原因：
  • Session 目录（如/tmp或自定义路径）无写权限

三、工程实践：正确授权方案

▶ 步骤 1：确认 PHP-FPM 用户

# 查看 PHP-FPM 配置grep"user\|group"/etc/php/8.1/fpm/pool.d/www.conf# 输出：# user = deploy# group = deploy

▶ 步骤 2：递归授权必要目录

# 授权 Laravel 典型目录sudochown-R deploy:deploy /www/wwwroot/app/storagesudochown-R deploy:deploy /www/wwwroot/app/bootstrap/cache# 设置安全权限sudofind/www/wwwroot/app/storage -type d -execchmod755{}\;sudofind/www/wwwroot/app/storage -type f -execchmod644{}\;

▶ 步骤 3：最小权限原则（安全加固）

• 仅授权必要目录：

  # ❌ 错误：整个项目授权chown-R deploy:deploy /www/wwwroot/app# ✅ 正确：仅授权写入目录chown-R deploy:deploy /www/wwwroot/app/storagechown-R deploy:deploy /www/wwwroot/app/bootstrap/cache

• 保留代码目录为只读：

  # 代码目录保持 root:root + 755sudochownroot:root /www/wwwroot/app/appsudochmod755/www/wwwroot/app/app

▶ 步骤 4：验证权限

# 模拟 PHP-FPM 用户写入sudo-u deploytouch/www/wwwroot/app/storage/test.logsudo-u deployrm/www/wwwroot/app/storage/test.log

四、避坑指南

五、终极心法

**“写权限不是开关，
而是信任的边界——

• 当你授权目录，
  你在划定能力；
• 当你最小化范围，
  你在铸造安全；
• 当你验证身份，
  你在确认上下文。

真正的系统稳定，
始于对权限的敬畏，
成于对细节的精控。”

结语

从今天起：

1. 部署后必检查storage和bootstrap/cache权限
2. 仅对必要目录授权，而非整个项目
3. 用sudo -u模拟 PHP 用户验证写入

因为最好的应用稳定，
不是祈祷不崩，
而是精准控制每一字节的归属。