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.

Why the exercise is a simulator

sethostname(2) requires CAP_SYS_ADMIN in the calling UTS namespace, and unshare(CLONE_NEWUTS) requires it too — the sandbox running your code has neither, and a real attempt returns EPERM. It costs nothing here, because a UTS namespace holds precisely two strings. Modelling it is not an approximation of the feature; it is the feature with the syscall wrapper removed.

Your exercise: UTS Namespace Isolation

Everything hinges on one behaviour: copy at creation, then total divergence. A rename in namespace 1 leaves namespace 2 on localhost; nothing propagates in either direction after the clone. That single rule, applied to a hostname here, is applied to a mount table, a device list and a uid map in the other lessons — which is why the smallest namespace is the one worth writing first. Note also what is not namespaced: sysname, release and machine come from the running kernel, are shared by everyone, and have no place in your state.