A worker reports as root inside its container but cannot set the host clock - why is root inside not root on the host?

## Two different things are both called "root" A container run quietly overloads the word. One meaning is **the id a process reports inside the boundary**: the number it gets back when it asks who it is, read against that container's own view of ids. The other is **the account that owns the machine**: the id the host kernel recognises when it decides whether this process may open that file, load that code, or change that machine-wide setting. Only the second one is ever enforced. Every permission decision is made against the host id the process actually carries, together with the set of privileges that process holds. The number the process reads back for itself is a label inside a view - useful for the software running there, not the thing being checked. This is why the two symptoms in the question sit side by side without contradiction. The worker really is id 0 as far as everything inside the boundary is concerned. It still cannot set the clock, because setting the clock is not something that id was given the authority to do. ## What the runtime removes before your process starts Root's authority on a machine is not a single switch. It is a set of separately grantable privileges, and a container runtime hands a new workload a small default subset of them. The ones normally withheld are the ones whose effect reaches past the boundary: - loading or unloading kernel code - setting the machine's clock - changing the host's network configuration or its packet-filtering rules - mounting and unmounting filesystems - rebooting the machine or writing kernel tunables - inspecting or tracing processes outside the container's own process table The ones normally kept are the ones whose effect ends at the boundary: changing ownership and modes on files inside the container's own root filesystem, signalling its own processes, binding ordinary ports, creating users that only exist in its own view. The rule worth carrying is that shape, not the list: **a privilege that would change something shared with the host is withheld; a privilege whose blast radius ends inside the container is kept.** There is one clock for the whole machine and one kernel for the whole machine. Neither is fenced per container, so neither can be handed to a workload without handing it the host. ## The three separations, side by side | What separates inside-root from host-root | What it does | What it does not do | |---|---|---| | The trimmed privilege set | Removes the host-wide operations from the process before it starts | Does not change which host id the process runs as | | Separate views of filesystem, process table and network | Shrinks what is reachable at all | Does not reduce authority over what remains reachable | | Id remapping | Translates inside ids onto unprivileged host ids | Is not switched on in every setup | The three are independent. A workload can have a trimmed privilege set and no remapping, or remapping and a generous privilege set. Knowing which of the three is doing the work in your environment is the difference between a model and a slogan. ## Where remapping fits, and why designs differ In one common arrangement the runtime itself is a privileged host service, and the container's id 0 is the host's id 0 - literally the same account, restrained by the trimmed privilege set, by the separate views, and by whatever confinement profile is applied. A file that process writes onto a host directory mounted into the container is owned by the host's root account. In the other arrangement, usually called **rootless**, the whole runtime is started by an ordinary unprivileged operator, and every id inside the container is mapped onto a range of unprivileged host ids that the operator is permitted to use. Inside id 0 becomes some high, unremarkable host id. That mapping is exactly what lets an unprivileged operator run a root-looking process at all: the process is root over the container's own view and over nothing else. So "root inside is not root outside" is true in both arrangements, but for different amounts of reason. The strongest version of the claim - that the inside-root process is just an ordinary unprivileged host user - only holds where remapping is on. Find out which arrangement you are in before you lean on it. ## What follows in practice 1. When a process that reports id 0 is refused an operation, read the **operation**, not the id. A refusal on setting the clock or loading kernel code is a withheld privilege, not a wrong file mode. 2. Whether inside-root is host-root decides what ownership appears on a host directory mounted into the container. That is the surprise teams hit first when they move between the two arrangements. 3. None of this makes running as inside-root a good posture. It explains why it is not automatically a disaster; the argument for running as an ordinary unprivileged account regardless is a separate, and stronger, one.