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），组内成员也无权写入。
TURF（开源）权限定制管理系统（以下简称“TURF系统”），是蓝水工作室推出的一套基于软件边界设计理念研发的具有可定制性的权限管理系统。TURF系统充分考虑了易用性，将配置、设定等操作进行了图形化设计，完全在web界面实现，程序员只需在所要控制的程序中简单调用一个函数，即可实现严格的程序权限管控，管控力度除可达到文件级别外，还可达到代码级别，即可精确控制到
- 先用
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 的补丁来硬套。安全边界不在数字里，而在每一层路径的权限是否都经得起“最小必要”推敲。
