linux不支持组嵌套，权限继承需显式设置default acl；组为扁平结构，/etc/group不允许多级包含，新建文件/目录仅通过default acl继承权限，且仅目录可设default acl。
Linux 不支持用户组嵌套（即一个组不能作为另一个组的成员），这是它和 Windows Active Directory 等系统的关键区别。权限继承也并非天然存在，必须通过 setfacl -d 显式设置默认 ACL 才能实现新建项的权限传递。
为什么没有组嵌套
Linux 的组模型是扁平结构，/etc/group 中每行定义一个组，其成员字段只列出用户名，不接受其他组名。试图把 groupB 写进 groupA 的成员列表，系统会当作无效用户名忽略——它不会报错，但也不会生效。
- 组之间无法形成父子或包含关系
- 权限只能靠用户“多归属”来模拟嵌套效果：让同一用户同时属于 groupA 和 groupB
- 若需批量管理，常用做法是用脚本同步用户到多个组，或借助外部工具（如 SSSD、LDAP）补充逻辑
权限继承靠 default ACL 驱动
普通 chmod 或 chgrp 不会影响未来创建的文件。真正起作用的是目录上的 default ACL，它像一个“模板”，只在新文件/子目录诞生时自动套用。
- default ACL 只对目录有效，对文件设置会报错
- 新建文件继承 default 中的 user/group 条目，但不继承 mask 和 other；新建目录则同时继承 default 条目及其自身的 default ACL
- 实际权限受 mask 限制：即使 default 设了 rwx，若 mask 是 r-x，最终也只生效 r-x
如何安全实现“类嵌套”协作场景
比如开发团队（devs）需要访问项目目录，而其中运维人员（ops）还需额外写日志权限。不能让 ops 组“属于” devs 组，但可以：
- 把 ops 成员全部加进 devs 组（用户多归属）
- 在项目根目录设 default ACL：
setfacl -d -m g:devs:rwX,g:ops:rwx /project - 显式提升 mask：
setfacl -m m::rwx /project，确保所有组权限完整生效 - 递归应用到现有子目录：
setfacl -R -d -m g:devs:rwX /project
常见误区提醒
很多人误以为改了父目录的 group 就能让子项自动继承，或者以为 chmod 775 能“传下去”。实际上：
- umask 控制新建文件的初始权限，但不决定谁可访问——那是 ACL 或组成员关系的事
- chgrp -R 改变现有项的属组，但不影响后续新建项
- 符号链接、硬链接不继承 default ACL；挂载点会中断 ACL 传递
