PHP 开发者应该理解的 Linux 入门权限指南

PHP 开发者应该理解的 Linux 入门权限指南

如果你曾经将 PHP 应用部署到 Linux 服务器并遇到 Permission denied 错误（通常出现在最糟糕的时候），你并不孤单。在理解 Linux 权限之前，它们确实会让人感到困惑。本文将帮助你理解 PHP 代码实际运行时涉及的用户、文件组以及那些 rwx 字母的真正含义。
原文链接-PHP 开发者应该理解的 Linux 入门权限指南

10秒速览

Linux 中的每个文件或目录都有：

• 一个所有者（用户）
• 一个所属组
• 三组权限：所有者权限、组权限和其他用户权限

权限分为三种：

• r = 读取
• w = 写入
• x = 执行（对文件）或"可进入"（对目录）

当 PHP 在服务器上运行时，你的代码通常以 web 服务器用户的身份执行（例如 Debian/Ubuntu 上的 www-data，CentOS/Red Hat 上的 apache，或者某些设置中的 nginx）------或者作为你配置的 PHP-FPM 池用户运行。大多数"在本地可以但在生产环境不行"的权限问题都可以归结为"到底是哪个用户在运行这段代码？"

专业解读权限

运行 ls -l 查看详情：

$ ls -l
-rw-r--r-- 1 deploy www-data  4238 Sep 17 10:12 index.php
drwxr-xr-x 2 deploy www-data  4096 Sep 17 10:12 public
drwxrwxr-x 4 deploy www-data  4096 Sep 17 10:12 storage

-rw-r--r-- 的解析：

• 第一个字符：文件类型（- 表示普通文件，d 表示目录）
• 接下来 3 个：所有者权限（rw-）
• 再 3 个：组权限（r--）
• 最后 3 个：其他用户权限（r--）

所以 index.php 对所有人可读，但只有所有者可写。

你还会看到所有者（deploy）和组（www-data）。如果 PHP-FPM 以 www-data 运行，通常最简单的修复方法是给组设置正确的权限。

八进制 vs 符号模式（以及何时使用）

你可以使用以下两种方式设置权限：

• 符号表示法：chmod g+w storage（给组添加写权限）
• 八进制表示法：chmod 775 storage（所有者 rwx=7，组 rwx=7，其他用户 r-x=5）

常用的八进制组合：

• 644 用于文件：所有者可读写，其他用户只读
• 755 用于目录：所有者完全权限，其他用户可读可执行
• 664/775 当组也需要写权限时（共享部署）

避免使用 777------这是安全风险，几乎从不需要。

文件 vs 目录：微妙但重要的区别

文件

• r：可以读取内容
• w：可以修改内容
• x：可以执行（作为程序或脚本运行）

目录

• r：可以列出目录中的文件名
• w：可以在目录中创建/删除/重命名条目
• x：可以进入（遍历）该目录

这就是为什么可写上传目录同时需要 w 和 x 权限：

# 对于 PHP 需要写入的上传目录：
chmod 775 uploads
# 或者如果只需要所有者写入：
chmod 755 uploads  # (但要确保所有权与 FPM 用户匹配)

所有权：chown 和 chgrp

如果 web 服务器用户需要写入某个目录（例如 storage、cache、uploads），需要调整所有权或组：

# 将 web 服务器组设为所有者组
sudo chgrp -R www-data storage

# 允许组写入（和进入）目录
sudo chmod -R g+rwX storage

大写的 X 只对目录（和已有的可执行文件）设置执行权限，这比通配符 +x 更安全。

如果你希望 web 服务器用户拥有文件：

sudo chown -R www-data:www-data storage

这在单用户服务器上很常见。在多用户部署中，建议保持代码库归人类用户所有（例如 deploy），同时使用共享组（例如 www-data）和组写权限。

umask：谁设置默认权限？

创建新文件时，它们会从一个"基础"值开始（通常是文件 666，目录 777），然后减去 umask 指定的权限。

• umask 为 022 会得到 644 文件和 755 目录
• umask 为 002 会得到 664 文件和 775 目录（组可写）

你可以在服务配置中（例如 PHP-FPM 的 systemd 单元文件）或 PHP 内部（进程范围内）设置 umask。

在 PHP 中（进程生命周期内）：

<?php
// 减少共享组部署的摩擦
umask(0002); // 新文件 664，目录 775

使用时要小心------这会影响调用后创建的文件。

PHP 的视角：我是谁？

你的脚本以 FPM 池用户的身份运行。快速诊断：

<?php
echo '运行用户: ' . get_current_user() . PHP_EOL;
echo '有效 UID: ' . posix_geteuid() . PHP_EOL; // 如果启用了 posix 扩展

以及经典的权限检查：

<?php
$path = __DIR__ . '/storage';
if (!is_dir($path)) mkdir($path, 0775, true);
if (!is_writable($path)) {
    error_log("$path 对 PHP 不可写");
}

记住：mkdir 中的 0775 会被当前的 umask 掩码。如果你传入 0777 但 umask 是 0022，最终会得到 0755。

实际场景（及合理默认值）

框架缓存和日志（Laravel、Symfony 等）

这些目录必须对 PHP 用户可写：

• storage/
• bootstrap/cache/
• var/cache/
• var/log/

设置组为 web 用户并使组可写：

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R g+rwX storage bootstrap/cache

如果有多个部署者/CI 代理写入这些目录，还要确保 umask 0002 以允许组写。

WordPress 和 CMS 上传

上传文件通常位于 wp-content/uploads（或类似目录）。保持代码只读；只让上传目录可写。

sudo chgrp -R www-data wp-content/uploads
sudo chmod -R 775 wp-content/uploads

核心和插件文件应该是 644（文件）和 755（目录）。如果由于权限过紧导致 WordPress 无法自动更新，考虑使用 SSH/CLI 部署，而不是放宽所有权限。

生产环境中的 Composer

最好在构建步骤中运行 Composer，而不是在生产环境。如果必须在生产环境运行：

# 以非 root 用户运行：
composer install --no-dev --optimize-autoloader

确保工作目录对该用户可写；不需要让 web 服务器用户拥有整个代码库。

使用 CI 的共享部署

在开发者和 web 服务器之间使用共享组（例如 deploy）：

sudo usermod -aG deploy www-data
sudo chgrp -R deploy /var/www/myapp
sudo chmod -R g+rwX /var/www/myapp
# 使新文件继承目录的组：
sudo find /var/www/myapp -type d -exec chmod g+s {} \;

最后一行在目录上设置了 setgid 位（稍后会详细介绍）。

特殊位：setuid、setgid、sticky

你偶尔会在 ls -l 中看到额外的字母：

• setuid （所有者的 s）：以文件所有者的权限执行文件（主要用于系统二进制文件）。PHP 应用中很少使用。
• setgid （组的 s）：在目录上：新文件继承目录的组------非常适合共享部署组。
• sticky 位 （其他用户的 t）：在像 /tmp 这样的目录上：用户只能删除自己的文件，即使目录对组/其他用户可写。

命令：

# 在目录上设置 setgid（继承组）
chmod g+s storage

# 设置 sticky 位（常见于共享临时目录）
chmod +t /var/www/myapp/tmp

当基本权限不够时：ACL

传统的 rwx 权限不够精细。ACL（访问控制列表）允许你为特定用户或组授予访问权限，而无需更改所有者：

# 允许 www-data 递归读写
sudo setfacl -R -m u:www-data:rwX storage

# 为 storage 中的新项目设置默认值
sudo setfacl -R -d -m u:www-data:rwX storage

ACL 非常适合需要一致写访问权限的 CI 管道或多个应用进程。

SELinux/AppArmor（简要说明）

如果你已经反复检查了权限，但仍然遇到 Permission denied，可能是 SELinux 或 AppArmor 等强制访问控制阻止了文件访问。在启用了 SELinux 的系统上，目录的上下文很重要（例如，可写 web 目录的 httpd_sys_rw_content_t）。不要禁用 SELinux------而是设置正确的上下文：

# 示例（支持 SELinux 的发行版）
sudo chcon -R -t httpd_sys_rw_content_t /var/www/myapp/storage

需要避免的安全陷阱

• 不要 chmod -R 777。这会授予所有人写权限，包括不受信任的系统用户或服务。
• 不要 以 root 身份运行 web 服务器。应该使用受限用户（www-data、apache、nginx）。
• 在生产环境中保持代码只读。只有数据目录（上传/缓存/日志）应该是可写的。
• 将构建与运行时分开。在 CI 中构建工件，部署工件，并保持运行时环境严格。

实用的、可重复的配置方案

以下是许多 PHP 应用的合理基准配置：

APP_DIR=/var/www/myapp

# 1) 所有权：人类用户所有，web 组
sudo chown -R deploy:www-data $APP_DIR
# 2) 严格的代码权限（文件 644，目录 755）
find $APP_DIR -type f -exec chmod 0644 {} \;
find $APP_DIR -type d -exec chmod 0755 {} \;
# 3) 可写的运行时目录（组可写 + setgid）
sudo chgrp -R www-data $APP_DIR/storage $APP_DIR/bootstrap/cache
sudo chmod -R 2775 $APP_DIR/storage $APP_DIR/bootstrap/cache  # 2 = setgid
# 4) 确保新文件继承组并组可写
sudo find $APP_DIR/storage $APP_DIR/bootstrap/cache -type d -exec chmod g+s {} \;
# 5) （可选）如果存在多个写入者，使用 ACL
sudo setfacl -R -m u:www-data:rwX $APP_DIR/storage $APP_DIR/bootstrap/cache
sudo setfacl -R -d -m u:www-data:rwX $APP_DIR/storage $APP_DIR/bootstrap/cache

这样可以在不开放过多权限的情况下，保持代码安全且运行时目录可写。

故障排除：解读"Permission denied"三部曲

1. 我是谁（在运行时）？

   • 检查 PHP-FPM 池用户，并用简单脚本验证（get_current_user()）。

2. 目标路径的权限/所有者是什么？

   • 使用 ls -l 和 namei -l /完整/路径/到/文件（非常适合查看路径上每个目录的权限）。

3. 是否有更高级的控制（SELinux/AppArmor）？

   • 在 SELinux 上，sudo ausearch -m avc -ts recent 或 sudo sealert -a /var/log/audit/audit.log 可以显示拒绝记录。

别忘了查看确切的 PHP 错误。例如：

Warning: fopen(/var/www/myapp/storage/app.log): failed to open stream: Permission denied

这通常意味着目录 缺少 PHP 用户/组的 w/x 权限------即使文件本身的权限看起来没问题。

快速参考："我应该设置什么？"

• 应用代码：文件 644，目录 755，所有者 deploy，组 www-data
• 可写数据（缓存/日志/上传）：目录 775（通常 2775 设置 setgid），组 www-data
• 避免：任何地方的 777
• 团队/CI 共享写入：在目录上设置 setgid + umask 0002，或使用 ACL

结论

Linux 权限并不神秘------它们只是关于谁 可以做什么 的规则。一旦你将这些规则与 PHP 的运行方式（你的 FPM/web 用户）对应起来，大多数问题都会迎刃而解。保持代码只读，只让数据目录可写，使用组（和 setgid）进行协作，在需要更精细控制时使用 ACL。只要稍加注意，你就能避免 Permission denied 的困扰，而不必使用 777 这样的危险命令。