UTS Namespace

After PID, mount, network, and user, the UTS namespace is almost comic relief: it isolates the hostname. (And the NIS domain name, which you will never use. "UTS" is a fossil from "Unix Time-sharing System" — the struct name in 1970s kernel code.) But its very smallness makes it the perfect specimen: every namespace mechanic, visible in miniature, with nothing else going on.

What it does

host$ hostname
prod-worker-07

container$ hostname
3f9a1c2b8d44          ← its own answer

container$ hostname api-1    ← root-in-container may change it…
host$ hostname
prod-worker-07               ← …host unaffected. That's the whole namespace.

One kernel value — the hostname — becomes per-namespace state. CLONE_NEWUTS at creation copies the parent's value; from then on, reads and writes inside the namespace touch only the private copy.

Why bother isolating a name?

Because software believes hostnames. Log lines, metrics tags, cluster-membership handshakes, TLS SNI defaults, shell prompts — all read hostname and treat it as identity. Two consequences drive the isolation:

• Containers need self-identity. Docker sets each container's hostname (the short container ID, or --hostname api-1), so a container's logs tag itself, not the machine it happens to share with forty siblings. Orchestrators lean on this — every Kubernetes pod gets its name as hostname, and plenty of clustered software (Kafka, Elasticsearch) advertises itself to peers by it.
• Containers must not rename the host. Changing hostname requires only namespaced privilege — remember user namespaces: root-in-container is admin of its bubble. Without UTS isolation, hostname pwned in one container would rename the machine for everyone — logs, monitoring, and all.

The namespace pattern, distilled

UTS shows the recipe with no distractions, and it's the same recipe all seven namespaces follow:

1. A clone flag (CLONE_NEWUTS) requests a fresh copy of some kernel state at process creation.
2. The child starts with a copy of the parent's state (hostname), not a blank (contrast: network starts nearly empty — each namespace picks its own initialization rule).
3. Reads/writes inside touch the copy; the parent's original is unreachable, not just protected.
4. Membership is inherited by children of the namespaced process — which is why a whole container (PID 1 and everything it spawns) shares one hostname without any coordination.

Hold this four-step template and the remaining namespaces (IPC next — same story for message queues and shared memory) are variations on initialization rules, not new ideas. Docker, at bottom, is: run one clone call with six flags, then furnish each fresh namespace.

Your exercise: UTS Namespace Isolation

Simulate it end to end: namespaces created (copying the creator's hostname), sethostname/gethostname operations resolving through the caller's namespace, children inheriting membership. The single behavior everything hinges on: copy at creation, then total divergence — a rename in the parent after the clone must not appear in the child, nor vice versa. Prove that in your simulator's tests and you've got the template all namespace understanding is built on — the rest of the course just applies it to more interesting state.