chmod 数字模式易设错因三位八进制对应“所有者|组|其他”且受 umask 影响；chown 组名错误会导致归属异常；setuid 对脚本无效；ACL 权限需关注 mask 限制。
chmod 数字模式为什么经常设错？
因为三位八进制数对应的是「所有者|组|其他」三类用户的权限组合，但很多人误把 rwx 当成二进制位直接相加，忽略了顺序和默认掩码影响。
-
755表示所有者可读写执行（rwx=4+2+1=7），组和其他用户只有读 + 执行（rx=4+1=5） - 常见错误：给脚本设
644—— 没有执行权限，./script.sh直接报Permission denied - 更安全的做法是先用
ls -l看当前权限，再按需增减：chmod u+x script.sh比硬记数字更不易出错 - 注意 umask 默认值（通常是
0022），它会“屏蔽”新建文件的某些权限，所以touch a出来的文件默认不是666而是644
chown 改属主时 group 名字写错会怎样？
系统不会报错，但实际归属可能变成数字 ID，后续权限判断失效，尤其在 NFS 或容器挂载场景下容易引发静默故障。
- 执行
chown user:group file前，先确认getent group groupname是否返回结果；没返回就说明组不存在 - 如果只改用户不改组，写成
chown user file即可，别写成chown user: file—— 后者会让组变成空字符串，等价于chown user:0 file - 批量修改时慎用
-R，比如chown -R www-data:www-data /var/www可能意外覆盖日志文件属主，导致 logrotate 失败
setuid/setgid 位在脚本里根本不起作用
Linux 内核从很早开始就忽略解释型脚本（如 #!/bin/bash）上的 setuid 位，这是明确的安全限制，不是配置问题。
- 现象：给
chmod u+s backup.sh后仍以当前用户身份运行，ps aux | grep backup.sh显示的 UID 没变 - 原因：内核只对二进制可执行文件检查
setuid，对脚本则交由解释器（如 bash）启动，而 bash 主动清除了特权 - 替代方案：用 C 写个薄包装器调用脚本，或改用
sudo配置免密规则（visudo中加%backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh） - 注意：
setgid对目录有效（新文件自动继承父目录组），但对脚本同样无效
ACL 权限比传统 rwx 更灵活，但也更容易留后门
ACL 允许给非属主 / 组的用户单独授权，但 getfacl 输出不易扫一眼看全，权限叠加逻辑也容易误判。
- 设置单用户读写：
setfacl -m u:alice:rwx /shared/dir；查看用getfacl /shared/dir，别只信ls -l - ACL 权限和基础权限是“取交集”生效的：即使给了
u:alice:rwx，如果目录基础权限是700（即组和其他无权），alice 仍可能因 mask 限制只能拿到r-x - mask 控制 ACL 的最大生效权限，修改 ACL 后建议显式更新：
setfacl -m m:rwx /shared/dir - 删除某条 ACL：
setfacl -x u:alice /shared/dir；清空全部 ACL：setfacl -b /shared/dir（注意这不恢复基础权限）
事情说清了就结束。权限问题最麻烦的不是不会设，而是设完看不出效果、出问题时查不出哪条规则在起作用。多用 getfacl 和 ls -l 对照看，比反复试错快得多。
