unshare(CLONE_NEWNS) failed in Dockerfile RUN, is this a bug?

[loynoir]

brief

unshare(CLONE_NEWNS) failed in Dockerfile RUN, is this a bug?

background

When I try to run nix flake within Dockerfile RUN

...

RUN nix ... run --option sandbox-fallback false ... /path/to/flake

nix failed, seems due to

NixOS/nix#16186 (comment)

0.184 unshare(CLONE_NEWNS)                    = -1 EPERM (Operation not permitted)
11.85 clone(child_stack=0x71f6e378eff0, flags=CLONE_NEWUSER|SIGCHLD) = -1 EPERM (Operation not permitted)
11.85 munmap(0x71f6e368f000, 1048576)         = 0
11.85 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x71f6e368f000
11.85 clone(child_stack=0x71f6e378eff0, flags=CLONE_NEWNS|CLONE_NEWPID|SIGCHLD) = -1 EPERM (Operation not permitted)

problem

1. unshare(CLONE_NEWNS) failed, is this a bug?

2. If this is not a bug, is there a reason?

3. If this is not a bug, what extra steps are needed to have unshare(CLONE_NEWNS)?

[dfbustosus]

This is expected sandbox behavior rather than a BuildKit bug.

The presence of /proc/self/ns/* means the process is already running in namespaces; it does not mean it has permission to create more. A normal RUN step lacks CAP_SYS_ADMIN and uses restricted seccomp/AppArmor settings, so root inside that step cannot create the mount namespace Nix requests. User-namespace creation can also be denied.

BuildKit's opt-out is RUN --security=insecure. It requires three independent permissions:

1. A Dockerfile frontend new enough to understand RUN --security (currently frontend 1.20 or newer).
2. The BuildKit daemon must allow the security.insecure entitlement.
3. The individual build request must request that entitlement.

For docker buildx build, create a dedicated builder:

docker buildx create \
  --name nix-insecure \
  --driver docker-container \
  --buildkitd-flags '--allow-insecure-entitlement security.insecure' \
  --use \
  --bootstrap

Mark only the Nix step that requires it:

# syntax=docker/dockerfile:1.20

FROM ...

RUN --security=insecure \
    nix ... run --option sandbox-fallback false ... /path/to/flake

Then request the entitlement for that build:

docker buildx build \
  --builder nix-insecure \
  --allow=security.insecure \
  --progress=plain \
  .

For standalone BuildKit, enable the daemon with either:

insecure-entitlements = ["security.insecure"]

or buildkitd --allow-insecure-entitlement security.insecure, and still invoke the client with buildctl build --allow security.insecure ....

The security warning is material: BuildKit documents insecure mode as equivalent to docker run --privileged. It grants all capabilities available to the daemon, relaxes seccomp/AppArmor, unmasks paths, and makes system filesystems writable. Use it only on a dedicated builder processing trusted Dockerfiles, contexts, and dependencies, never an untrusted-PR or multi-tenant builder.

A rootless or containerized daemon has an additional boundary: this entitlement can grant only privileges already available inside the daemon's outer user namespace and capability set. It cannot override an outer seccomp/AppArmor policy or host user-namespace restriction. If it still returns EPERM, use a trusted rootful dedicated builder rather than expecting security.insecure to escape those outer restrictions.

If the real requirement is only network isolation, a safer but behaviorally different option is RUN --network=none with the Nix sandbox disabled. That blocks networking for the whole step and may require separate fetch and offline-build stages; it is not equivalent to Nix's per-derivation sandbox.

References: matching maintainer answer, RUN --security requirements, Buildx entitlement example, daemon configuration, and rootless restrictions.