Linux不支持原生角色概念，需用group+sudo+ACL三层组合实现RBAC；useradd仅建独立账户，无法动态切换角色；权限应按命令粒度通过sudoers中的Command Alias精细控制，并辅以ACL解决目录级细粒度需求。

Linux 用户权限本身不支持“角色”概念，所谓多角色场景必须靠 group + sudo + 文件系统 ACL 三层组合实现，硬套 RBAC 模型会出问题。

为什么不能直接用 useradd 创建“运维角色用户”

Linux 的 useradd 只创建独立账户，每个用户有唯一 UID，无法动态切换角色。强行给一个用户加一堆 group（比如同时属于 dev、ops、dba）会导致权限叠加失控，且审计时无法区分“此刻他以什么身份操作”。

• 真实场景中，开发人员临时需要重启服务，应走 sudo systemctl restart nginx，而非给他 root 权限或加入 systemd-journal 组
• groups 是静态成员关系，不是运行时上下文；sudo -u 或 sudo -g 才能模拟角色切换
• 用 usermod -aG ops,dev alice 看似方便，但一旦 ops 组获得新权限（如写入 /opt/deploy），alice 就自动获得——这违反最小权限原则

sudoers 配置要按命令粒度控制，不是按组放行

/etc/sudoers 里写 %ops ALL=(ALL) ALL 和没设权限一样危险。真正可控的做法是为每类操作定义明确的 Command Alias，再绑定到对应组。

%dev    ALL=(www-data) /usr/bin/systemctl start nginx, /usr/bin/systemctl reload nginx
%ops    ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx*
%dba    ALL=(postgres) /usr/bin/psql -U appdb -d appdb -c *

• 必须用 visudo 编辑，避免语法错误锁死 sudo
• 别用通配符 * 匹配 SQL 语句，应限制具体命令路径和参数白名单（如用 Defaults env_check += "PGPASSWORD" 配合固定密码变量）
• (www-data) 表示以 www-data 身份执行，比 su - www-data -c 更安全，不会继承 shell 环境变量

敏感目录需用 ACL 补充 group 权限的粒度缺陷

当多个角色需对同一目录有不同读写权限（例如：开发可写 /var/www/html 下文件，但不能删目录；运维可删文件但不能改代码），仅靠 chgrp + chmod g+w 不够。

• 先启用文件系统 ACL 支持：mount -o remount,acl /（确认 /etc/fstab 中已有 acl 选项）
• 设置基础权限：chmod 775 /var/www/html && chgrp webdev /var/www/html
• 追加 ACL：setfacl -m g:dev:rwx,g:ops:rx /var/www/html，再对子目录递归：setfacl -d -m g:dev:rwx,g:ops:rx /var/www/html
• ACL 优先级高于传统 group 权限，且 getfacl /var/www/html 可审计，比改 umask 或写 wrapper script 更可靠

最常被忽略的是 session 级别的上下文隔离：即使 sudo 配置正确，用户仍可能用 sudo su - 切换到 root 后绕过所有限制。生产环境必须禁用 sudo su 类命令，并在 /etc/sudoers 中加 Defaults !authenticate（针对已登录用户）或用 pam_wheel 强制二次认证。