实现服务器权限继承与覆盖规则，核心是文件系统级继承（setgid+统一属组）、用户身份归属（主组+umask）、执行行为控制（sudoers）、跨主机同步（堡垒机）四层机制协同；缺一不可。
管理服务器权限继承与覆盖规则，核心在于理解“谁在什么位置能做什么”这件事不是靠直觉，而是靠机制协同——不是简单设个组就自动生效，也不是加一条规则就全局覆盖。关键是要分清层次：文件系统级的继承、用户身份归属、执行行为控制、跨主机同步，四者缺一不可。
用 setgid + 统一属组实现协作目录的稳定继承
这是 Linux 下最可靠、最易验证的继承方式，不依赖复杂配置，也不受 ACL 兼容性影响：
- 对协作目录（如 /srv/webapp）执行
chmod 2775 /srv/webapp，其中开头的 2 表示启用 setgid 位 - 确保目录属组为业务组（如
chgrp webdev /srv/webapp） - 所有参与协作的用户主组设为该组（
usermod -g webdev alice），避免新建文件误用其他组 - 配合全局 umask 002（在
/etc/login.defs或 PAM 中设置），使新建文件默认为 664、目录为 775 - 验证：普通用户在该目录下
touch test && ls -l test，确认属组正确、组权限含 w
用 default ACL 补充细粒度继承需求
当 setgid 无法满足多角色、差异化访问时，ACL 是必要补充，但必须明确其作用边界：
- default ACL 只对新创建的文件/子目录生效，不影响已有项：
setfacl -d -m g:deploy:r-x /srv/webapp - 新目录会同时继承 default ACL 和自己的 default ACL，可递归设置：
setfacl -R -d -m u:monitor:r-- /var/log/app - mask 是实际生效的权限上限，若发现权限没生效，先检查 mask：
getfacl /srv/webapp查看 mask:: 行，必要时手动提升：setfacl -m m::rwx /srv/webapp - 注意：硬链接、符号链接、NFS 挂载目录可能不遵循 default ACL，需单独验证
用 sudoers 和组策略控制执行权限，而非文件权限
文件归属和读写权限 ≠ 操作能力。管理员行为必须通过执行层约束：
- 按职能建独立组（如 dbadm、netadm），禁止交叉加入
- 在
/etc/sudoers中精确授权命令路径，例如：dbadm ALL=(postgres) /usr/bin/pg_dump, /usr/bin/psql - 敏感目录（如
/etc/nginx）用 ACL 限制访问：setfacl -m g:webdev:rx /etc/nginx，不给写权 - 禁用直接 su 到 root，改用
sudo -i或指定命令，确保操作可审计
跨主机环境用堡垒机统一继承逻辑
单台服务器配得再好，多台机器人工同步极易出错、延迟或遗漏：
- 引入 Jumpserver 等堡垒机，在平台侧定义“中间件运维组”，统一授权访问 N 台目标服务器
- 用户只加入堡垒机组，无需在每台机器上重复建用户、加组、配 sudo 规则
- 支持嵌套组关系（如“应用组”隶属“生产环境总控组”），权限变更后自动同步至所有关联资产
- 人员离职时，仅需从堡垒机组移出，即完成全部主机权限回收
不复杂但容易忽略：权限继承从来不是“设一次就永远生效”的功能，而是需要 umask、属组、setgid、ACL、sudoers、集中管控层层对齐的结果。每次新增协作成员或调整职责，都应同步检查这五个层面是否一致。
