服务器权限继承与覆盖规则如何管理

实现服务器权限继承与覆盖规则，核心是文件系统级继承（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、集中管控层层对齐的结果。每次新增协作成员或调整职责，都应同步检查这五个层面是否一致。