Linux用户管理规范设计_权限分配原则解析【教程】

权限规范的核心是系统性拒绝默认权限，而非随意加权；应坚持最小粒度授权，禁用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 参数，否则协作目录权限会在备份后悄然失效。