rwx对文件和目录含义不同：文件r=读内容、w=改内容、x=执行；目录r=列文件名、w=增删改文件、x=进入及访问子路径，混淆将导致权限越界。
为什么 rwx 不是“能读/能写/能执行”那么简单
因为 r、w、x 对文件和目录的含义完全不同，混淆这点是绝大多数权限越界问题的根源。比如给一个目录设了 r 但没给 x，其他用户连 ls 都会 Permission denied；反过来，只给 x 没给 r，用户能 cd 进去，却看不到里面有什么文件——这本身就是一种隐蔽的访问控制。
-
r对文件 = 读内容；对目录 = 列出文件名（ls） -
w对文件 = 修改内容；对目录 = 在其中创建/删除/重命名文件（哪怕文件本身权限是444） -
x对文件 = 当作程序运行；对目录 = 进入该目录（cd）、访问其子路径（如cat /home/user/a.txt要求/home、/home/user都有x）
777、644 这些数字背后的真实风险边界
数字权限不是“方便好记”，而是直接暴露最小安全交集。例如 755 表示“其他用户可进入目录、可读可执行文件”，但如果你把 Web 日志目录设成 755，攻击者就能直接下载 access.log 查到所有请求路径；而 600 看似保险，但如果它是某个服务的配置文件且属主是 root，普通用户连 cat 都不行——可一旦服务以非 root 用户运行，又可能因权限不足无法读取，导致启动失败。
- 敏感配置文件（如
/etc/shadow）必须是600或400，且属主为root - Web 可执行脚本（如 PHP/Python）应避免
x给others，用750+ 正确属组更稳妥 - 日志目录建议
750或755，但具体日志文件本身应为640，防止被直接 cat 或下载 -
777几乎永远不该出现——它等于主动关闭所有访问隔离
chown 和 chmod 的配合才是真实防线
光调 chmod 不改属主属组，就像锁门却不换锁芯。比如财务部门要共享一个报表目录，你设了 770，但若目录属组还是 root，财务用户根本进不去；反之，如果属组正确但没开组权限（如仍用 755），组内成员也无权写入。
- 先用
chown user:finance /shared/finance-reports明确归属 - 再用
chmod 770 /shared/finance-reports开放组内完全访问 - 对目录内新生成文件自动继承组权限，需额外开启 setgid：
chmod g+s /shared/finance-reports - 禁止用
chown -R root:root /var/www这类粗暴操作——它会覆盖服务进程所需的实际属主（如www-data）
ACL 是 rwx 失效时的兜底方案，但别滥用
当标准 UGO 模型撑不住复杂协作（比如让开发组 A 读、运维组 B 写、审计员 C 只读特定文件），setfacl 才是解法。但它不是“更高级的 chmod”，而是叠加层——基础权限仍生效，且 mask 会截断 ACL 权限上限。常见坑是：加了 user:alice:rwx 却发现 alice 还是没权限，其实是 mask 被卡在 r-x，得同步更新：setfacl -m m:rwx file。
- 查看是否启用 ACL：检查挂载选项是否有
acl（mount | grep " / "） - 添加单用户权限：
setfacl -m u:alice:rw file - 删除某条 ACL：
setfacl -x u:alice file - 慎用递归 ACL（
-R），尤其对大目录，性能损耗明显，且易误伤系统文件
真正危险的从来不是“不知道怎么设 755”，而是忽略目录的 x 权限链、混淆文件与目录的 w 含义、或者把 chown 当成 chmod 的补丁来硬套。安全边界不在数字里，而在每一层路径的权限是否都经得起“最小必要”推敲。
