User namespaces: map identities without inventing host authority

A mapping line specifies an inside start, an outside start, and a positive count. For a directly stated parent-relative interval, each inside ID in that interval maps to the corresponding outside offset. Outside the mapped ranges, the identity is not silently wrapped into another valid user. Kernel interfaces can reject operations or display an overflow identity according to their contracts. Read uid_map and gid_map in the relevant observing namespace, because the displayed outside relation can depend on who opens the mapping file.

Mapping setup is constrained by kernel permissions and is not an arbitrary write granting access to every host identity. Rootless tools commonly rely on authorized subordinate-ID ranges and privileged mapping helpers where needed. Group mapping has additional rules; unprivileged setups commonly must disable setgroups before writing the allowed gid_map under the kernel's permission conditions. This is a setup protocol to follow precisely, not a universal instruction to remove groups in every environment or proof that a single configuration works on every kernel.

Capabilities are associated with user-namespace relationships and the namespaces that own the affected resources. Being privileged in a child user namespace does not mean possessing the corresponding capability in the initial namespace. A host file's ownership, mount mapping, ordinary permission bits, ACLs, and LSM policy still affect access. Likewise, sharing a network namespace or passing a privileged file descriptor can expose resources independently of the visible UID. Identity translation is one part of an access decision, not the entire decision.

A bind-mounted directory can therefore present surprising ownership without any kernel bug. A file owned by parent UID 100042 maps naturally to inside UID 42 under the example range, while a different parent ID may be unmapped. An idmapped mount can introduce another supported ownership interpretation at the mount boundary, which must not be confused with recursively changing file owners. Record both the process user namespace and the mount's actual mapping before applying chown as a speculative repair.

For a reproducible fixture, record the namespace identities, mapping files, effective credentials, file ownership, and mount attributes. Test access with the same UID, groups, capabilities, and inherited descriptors as the intended workload. A successful read as an administrator outside the container does not establish that the container should be able to read the same path. Conversely, a failed write may come from a read-only mount or LSM denial rather than the UID map. Change one mechanism at a time so the result has an interpretable cause.

The modular lab deliberately contrasts a cyclic map with UID translation. Reset, explicitly set modulus twelve and additive step five, predict the repeating residue orbit, then Play or Step. For another run Reset and explicitly set modulus twelve and step four. The first orbit has twelve residues and the second three. UID ranges do not follow either wraparound rule: an unmapped inside ID must not become an authorized outside ID by reducing it modulo a count. This arithmetic instrument contains no kernel credentials, mapping files, permissions, or namespace boundary.