linux服务器无原生组权限自动继承，需通过setgid（chmod 2775）、统一umask 002、用户主组设为目标组、默认acl（setfacl -d）及sudoers分权协同实现：协作目录新建文件/子目录自动归属目标组且组可写，权限按角色精确管控并支持跨主机集中同步。
Linux服务器上没有真正的“组权限自动向下继承”机制，所谓继承，是通过目录属性、用户配置和访问控制规则协同实现的协作效果。核心目标是：新创建的文件和目录自动归属目标组、默认具备组内可写权限、成员操作时按统一策略生效。
启用setgid实现属组自动继承
这是最稳定、最基础的继承手段，解决“新建内容归谁”的问题：
- 将协作目录（如/srv/app）属组设为目标组（如devs）：chgrp devs /srv/app
- 启用setgid位并设置合理权限：chmod 2775 /srv/app（2表示setgid，775表示所有者与组可读写执行，其他人仅读执行）
- 此后在该目录下新建的子目录自动以devs为属组，且自带setgid位；新建文件也自动归属devs组，组权限可写（需配合umask）
统一umask与主组确保权限一致性
仅靠setgid无法保证所有用户新建文件都带组写权限，必须同步规范环境：
- 将目标组设为用户的主组：usermod -g devs alice（避免用户用私有组创建文件）
- 全局配置umask为002：在/etc/login.defs中设UMASK 002，或通过PAM模块统一控制
- 验证方式：普通用户在协作目录中执行touch test && ls -l test，确认属组为devs、权限含rw-（如-rw-rw-r--）
用默认ACL细化新建项权限
setgid管归属，ACL管权限细节。当需要更精细控制（如特定用户/组对新文件有不同权限）时使用：
- 为目录设置默认ACL：setfacl -d -m g:devs:rwx /srv/app（新子目录继承rwx，新文件继承rw-）
- 若还需覆盖现有内容，再补一条非默认ACL：setfacl -R -m g:devs:rwx /srv/app
- 注意mask影响：ACL实际生效受mask限制，必要时显式提升：setfacl -m m::rwx /srv/app
- 查看是否生效：getfacl /srv/app，输出中含default:开头的行即已配置
分层授权与集中管控
文件归属与默认权限解决协作问题，但管理员行为需按角色隔离：
- 职能分离：为运维、安全、数据库等角色建独立组（如opsadm、secadm），禁止交叉加入
- sudo精确授权：在/etc/sudoers中按组授权，例如：opsadm ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
- 跨主机统一管理：引入堡垒机（如Jumpserver），在平台中定义“中间件组”，授权其访问多台服务器，用户加入该组即自动获得对应权限，离职时移出组即完成回收
