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，再绑定到对应组。
Work Productivity Word Mail Workflow Helper
下载
构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等
%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 强制二次认证。
