网站目录权限怎么给：chown 与用户组的实践

网站被入侵的事后复盘里，"某个目录给了 777"出现的频率一直不低。目录权限的本质就一句话：让该写的进程能写，其他一律收窄。 先搞清谁在跑网站 ps aux | grep nginx 看一眼 worker 进程的用户，Ubuntu 上常见 www-data，CentOS 上常见 nginx，PHP-FPM 同理。文件权限是给这个运行用户看的，不是给你登录的账号看的。看目录权限别用肉眼逐层数，namei -l /var/www/html/uploads/a.log 会沿路径把每一层的权限列出来。 基本盘：755 与 644 代码目录属主设为部署用户，运行用户只读：chown -R deploy:deploy /var/www/html，再配 755 目录、644 文件。nginx 读得到、写不了，即使被传了 webshell 也难以落地。 可写目录单独拎出来 上传目录、缓存目录必须可写，就只把它们交给运行用户： chown www-data:www-data /var/www/html/uploads chmod 750 /var/www/html/uploads 整站只开这一个可写口子，其余保持只读，按最小暴露面原则取 750 比 755 更稳。上传目录再加一道锁：nginx 配置里对 uploads 禁用 PHP 解析，就算传上来脚本也无法执行。团队协作再进一步：chgrp www-data /var/www/html 后给目录加 setgid 位（chmod 2755），新文件自动继承组，部署用户与运行用户各取所需。 验证方式 别凭感觉，直接扮演运行用户试一下：sudo -u www-data test -w /var/www/html/uploads && echo writable，输出 writable 才算数。换个用户再试一遍返回空，才说明收窄到位。 报错也要分家 403 大多是文件权限或 SELinux 拦截，502 则是 PHP 进程本身没响应，两类错误混为一谈，权限调半天也白调。CentOS 上开了 SELinux、chown 调完还是 403 的，多半卡在安全上下文：ls -Z 看类型，网页目录应为 httpd_sys_content_t，挪动过的目录用 restorecon -Rv /var/www/html 恢复默认规则。权限调整尽量固化成脚本放进版本库：chown、chmod、目录清单写成一份 init 脚本，新机器照着跑，人和记忆都不再是单点。 收尾一个习惯：上线前把全站扫一遍 777，find /var/www -perm 777，找到的多半是历史遗留，逐个收窄。权限这事不怕紧，怕的是图省事的一把梭。