linux中mail、wheel等特殊组本身无固有权限，权限完全取决于配置：mail组仅为历史标识，无默认策略；wheel组在红帽系中通过/etc/sudoers的%wheel行和/etc/pam.d/su的pam_wheel.so启用sudo与su限制；其他内置组如adm、disk等亦需显式配置文件权限或策略才生效。
Linux 中的 mail、wheel 等“特殊组”本身不自带底层权限，它们的权限完全取决于系统配置——不是组名决定权限，而是配置文件赋予语义。
mail 组：仅语义约定，无默认权限
mail 组在绝大多数发行版中只是一个历史遗留标识：
- /etc/group 中存在 mail:x:12:，但该组不控制任何系统行为
- 传统上用于运行邮件服务（如 sendmail、postfix），但现代系统中服务进程通常使用专用低权限用户（如 postfix、mailnull），而非依赖 mail 组成员身份
- 没有默认 PAM 规则、sudoers 条目或文件属组策略绑定到 mail 组
- 即使用户属于 mail 组，也不会自动获得读取 /var/spool/mail 或管理邮件队列的权限——这些需显式通过文件 ACL、目录属组或 sudo 配置授予
wheel 组：红帽系的权限“开关组”，靠配置激活
wheel 是唯一被主流发行版（RHEL/CentOS/Fedora/Rocky/Alma）赋予明确管理语义的内置组，但权限非固有，全靠两处配置启用：
萃智引擎 (TRIZ Engine)
下载
一款AI图像与设计工具，主要用于基于TRIZ理论的AI工程创新平台，为工程师提供复杂机械机理实时渲染、物理级运动仿真、矛盾矩阵求解及AI创新灵感生成，适合需要提升相关任务效率的用户。
-
/etc/sudoers 中的 %wheel 行：如
%wheel ALL=(ALL) ALL，表示该组成员可执行 sudo 命令（需输自己密码） -
/etc/pam.d/su 中的 pam_wheel.so：启用后配合
SU_WHEEL_ONLY yes（在 /etc/login.defs），才限制仅 wheel 成员可用 su 切换 root - GID 通常为 10，但仅是编号；若未配置上述两项，wheel 组与普通组无异
- 用户加入 wheel 后无需重启服务，权限即时生效（因 sudo 和 su 运行时动态查组）
其他常见内置组（daemon、sys、adm、disk 等）：纯逻辑分组，无策略绑定
这些组存在于 /etc/group，但系统不强制赋予任何特权：
- daemon、sys、bin：早期 Unix 遗留，现仅作服务进程归属参考，不参与权限决策
- adm：传统上用于日志查看（如 /var/log），但实际能否读取取决于文件属组和权限位（如 /var/log/messages 常属 adm 组且权限为 640），组本身不授权，是文件权限设置的结果
- disk：理论上可访问块设备（/dev/sd*），但现代系统要求 udev 规则 + 权限位 + 可能的 polkit 策略，仅属 disk 组不足以绕过限制
- 所有这类组的 GID 固定（如 adm=4, disk=6），但系统不检查它们来放行操作——除非管理员手动在 sudoers、PAM 或文件权限中引用
真正起作用的是配置，不是组名
区分关键点：
- 看
visudo输出：是否有%组名行？有则该组参与 sudo 授权 - 看
cat /etc/pam.d/su | grep wheel：是否启用 pam_wheel.so？决定 su 限制 - 看
ls -l /var/log/等敏感路径：文件属组是否设为某组 + 权限位是否开放（如 640 表示组可读）？这才是实际权限来源 - 用
id 用户名查所属组，再结合上述配置，才能判断该用户实际拥有什么能力
