执行组列表¶
鹤思在每个作业和作业步请求中使用一个有序的 GID 列表：
前端收集有效 GID 和进程的 supplementary group，去重后保证有效 GID
位于首项。这组执行组始终对应提交者在宿主机上的权限，包括容器作业的
批处理脚本和通过 ccon run 提交的子步骤。
后端在每个执行节点按提交者身份执行最终校验。有效 GID 必须存在于该用户在节点的 组集合中；主 GID 缺失时在 payload 启动前失败。supplementary GID 只取 与节点实际组的交集；有请求的补充组被移除时，步骤只提示部分补充组已移除， 不列出具体 GID 或数量，并继续执行。节点存在但前端未请求的额外组不会 自动加入，也不会触发告警。
多节点作业步必须先由所有分配节点完成主 GID 校验，才能确认分配成功。 任一节点失败都会阻止部分 payload 启动，并继续执行原有状态上报、cgroup 清理和资源释放。
容器身份¶
提交者在宿主机上的身份与容器内的运行身份相互独立。ccon --user 和
cbatch --pod-user 只选择容器内的运行身份，不会改变提交者在宿主机上的组权限。
- 未启用 user namespace：容器以提交者的 UID、有效 GID 和节点校验后的补充组启动。 显式指定的 UID/GID 必须与提交者 UID/EGID 一致，root 提交者也遵循此规则。
- 启用 user namespace：默认容器身份为
0:0，可用--user/--pod-user指定节点映射范围内的 UID/GID。作业只使用提交者的有效 EGID，不携带补充组。 属于多个宿主机组的用户仍可提交 userns 作业，但作业不保留补充组权限。 容器 UID/GID 无须存在于宿主机 NSS。
只指定 UID 时，省略的 GID 使用该模式的默认值：userns 为 0，非 userns 为提交者 EGID。
两个模式均设置 CRI SupplementalGroupsPolicy=Strict，避免镜像的
/etc/group 自动追加组；容器运行时须支持此策略。
独立容器作业在前端取得提交身份、确定脚本和命令行中的最终 userns 选项后， 仅保留有效 EGID，再校验身份。容器子步骤继承父作业的 Pod 设置；启用 userns 时， 调度端还会在校验前将子步骤的组列表替换为父作业的有效 EGID。 即使提交子步骤的进程仍带有补充组，或其 EGID 与父作业不同，也按父作业身份执行。 调度端和执行节点继续校验 userns 仅使用单个有效组的限制。
userns 的 UID/GID mapping 使用该账户现有的 SubUID/SubGID 区间；SubGID 自动分配
仍以账户 NSS 主 GID 选择区间，不因某次提交的 EGID 改变而重新分配。
namespace 映射始终从容器 ID 0 开始，不随指定的运行身份变化；节点在启动 payload 前，
分别按实际 UID/GID 映射区间校验指定值。
原生 idmapped mount 和 bindfs 均把提交者 UID/EGID 对应到指定的容器 UID/GID（默认 0:0），
挂载转换和新文件创建组不再假定 EGID 等于 NSS 主 GID。
目前不支持 userns 下继承宿主机补充组的挂载权限。