权限规范的核心是系统性拒绝默认权限，而非随意加权；应坚持最小粒度授权，禁用777、sudo组滥用、通配符命令等高危操作，严格管控sudoers、用户创建流程及ACL使用边界。
root 账户不应直接用于日常操作，普通用户也绝不能长期持有 sudo 全权限；真正的权限规范不是“怎么加权限”，而是“如何系统性地拒绝默认权限”。
为什么不能用 chmod 777 或 usermod -aG sudo 解决问题
这类操作看似快捷，实则绕过所有安全边界：777 让任意进程（包括被入侵的 Web 服务）可读写执行该文件；而把用户加入 sudo 组等于授予其等同于 root 的全部能力——哪怕他只需求重启某个服务。
- 真实风险案例：某运维为方便部署，将 CI/CD 用户加入
sudo组，结果因 Jenkins 插件漏洞导致攻击者直接获取 root shell - 替代方案永远优先考虑最小粒度授权：用
visudo写明具体命令路径、参数限制和免密条件 - 敏感目录如
/etc/shadow、/root/.ssh必须保持600，连组成员都不能读——ls -l /etc/shadow输出应为-rw------- 1 root root
sudoers 文件里必须禁用的三类通配符写法
很多团队在 /etc/sudoers 中滥用模糊语法，导致权限失控。以下写法看似灵活，实为高危配置：
-
%admin ALL=(ALL) NOPASSWD: /usr/bin/systemctl *——*允许执行任意 systemctl 子命令，含systemctl edit --full sshd修改服务配置 -
%devs ALL=(ALL) /bin/bash—— 直接赋予交互式提权 shell，绕过所有命令级审计 -
Defaults env_reset缺失时，攻击者可通过LD_PRELOAD注入恶意库劫持 sudo 命令行为
正确写法示例（仅允许重启 nginx）：
%webops ALL=(root) NOPASSWD: /bin/systemctl restart nginx.service
用户创建时必须同步执行的四步加固动作
新建用户不是 useradd 加 passwd 就完事。漏掉任一环节都可能留下后门：
- 强制设置非交互登录 Shell：
usermod -s /usr/sbin/nologin username（服务账户）或/bin/bash（人工账户） - 禁用空密码与弱密码策略：确认
/etc/pam.d/common-password含pam_pwquality.so retry=3 minlen=12 difok=3 - 清理默认继承的危险权限：检查
~username/.bashrc是否含export PATH="/tmp:$PATH"类路径污染 - 绑定专属主目录权限：
chmod 750 /home/username+chown username:username /home/username，禁止组内其他用户进入
ACL 与传统权限的分工边界在哪
当标准三元组（所有者/组/其他）无法满足协作需求时，才启用 ACL；它不是“更高级的 chmod”，而是为特定例外场景设计的补丁机制。
- 适用场景：多个项目组需共享
/srv/app-data，但 A 组可读写子目录a/，B 组只能读b/，且不能互相看到对方文件 - 禁用场景：仅为给单个用户加读权限就用
setfacl——此时应改组归属或加到对应组 - 关键陷阱：
getfacl输出中若出现mask::---，说明 ACL 实际未生效（mask 权限低于显式设置值），必须先setfacl -n清除再重设
最易被忽略的一点：ACL 权限不随 cp 复制继承，rsync -a 也不保留；需要显式加 --acls 参数，否则协作目录权限会在备份后悄然失效。
