不能直接加sudo组或设777权限，因为这等于交出系统控制权：sudo组允许执行任意命令（如rm -rf /），777使被攻陷服务可随意读写敏感文件；真实案例中ci/cd账户因漏洞致root沦陷。
为什么不能直接加 sudo 组或设 777 权限
因为这不是授权，是交出系统控制权。把用户加进 sudo 组，等于允许他执行任意命令——包括 rm -rf /、修改 /etc/shadow、替换 SSH 密钥。而 chmod 777 目录，会让任何进程（比如被攻陷的 Web 服务）随意读写执行其中文件，日志、配置、私钥全暴露。
- 真实案例：CI/CD 账户加入
sudo组后，因 Jenkins 插件漏洞，攻击者直接拿到rootshell -
/etc/shadow必须保持-rw-------（600），连同组用户都不能读 - 敏感目录如
/root/.ssh、/var/log/journal同样禁止组和其他用户遍历
怎么创建真正隔离的服务账户
服务账户不是“能登录的普通用户”，而是以最低权限运行程序的专用身份。它不该有密码、不能交互登录、不共享家目录、不继承危险环境变量。
- 用
useradd -r -s /sbin/nologin appuser创建系统级账户（UID 自动分配在 1–499） - 禁用密码：执行
passwd -l appuser，避免/etc/shadow中留空或弱密 - 绑定专属目录：
chown appuser:appuser /opt/myapp && chmod 750 /opt/myapp - 清理默认
.bashrc：删掉export PATH="/tmp:$PATH"类路径污染语句
组权限怎么配才不越界
组不是“权限批发商”，而是按职能切分的访问域。一个用户可属多个附加组，但每个组只管一件事；文件归属要靠 setgid 和主组继承来稳定传递，不能靠手动 chown 救火。
- 先建职能组：
groupadd -g 1001 webadmin && groupadd -g 1002 dboperator - 用户加组用
usermod -aG webadmin,dboperator deployer，不改其主组 - 关键目录启用
setgid：chgrp webadmin /var/www/html && chmod g+s /var/www/html，确保新文件自动属该组 - 避免用
chmod g+w开放写入，改用 ACL 精确授权：setfacl -m u:deployer:rwx /var/www/html
sudoers 规则怎么写才安全
sudo 不是提权入口，是受控的命令通道。所有规则必须限定具体二进制路径、禁止通配符、禁用 shell 逃逸、重置环境变量。
- 绝对不要写
/usr/bin/systemctl *或/bin/bash——前者等于开放全部服务管理，后者直接绕过审计 - 正确写法：
%webops ALL=(www-data) NOPASSWD: /bin/systemctl restart nginx.service - 必须包含
Defaults env_reset，否则攻击者可用LD_PRELOAD注入劫持命令行为 - 策略单独存于
/etc/sudoers.d/deploy-policy，用visudo -f编辑，避免语法错误锁死 sudo
最常被跳过的一步是：新建用户后没立刻检查 /home/username/.bashrc 和 umask 设置。哪怕权限数字全对，一个恶意 PATH 或宽松 umask 002 就能让新文件默认可被组内其他用户修改——这种细节，不查就永远藏在权限模型的阴影里。
