[ronandi]

Fixes #2041.

Problem

container 1.2.0 picked up containerization's secure-by-default changes (default readonlyPaths includes /proc/sys, restricted capability set) with no CLI opt-out. Guests can no longer write sysctls or remount mounts, so Kubernetes node images (kindest/node, rancher/k3s) and docker-in-docker engines like dagger fail to boot.

Change

Two Docker-compatible flags on run/create:

• --sysctl key=value (repeatable): sets guest sysctls at creation. vminitd applies them before the read-only remount, so they compose with the default readonly paths.
• --privileged: grants the full capability set and clears the default masked/readonly paths. Every container is its own VM with its own kernel, so an explicit opt-in escape hatch is proportionate and matches Docker's UX.

The API plumbing (sysctls, readonlyPaths, maskedPaths on ContainerConfiguration) already existed — this exposes it.

Verification (against 1.2.0 services)

• --sysctl net.ipv4.ip_forward=1: value lands in the guest (cat = 1)
• --privileged ubuntu: sysctl -w succeeds, mount -o remount,ro /sys succeeds
• --privileged kindest/node:v1.36.1: boots cleanly (containerd active, kubelet starts) — fails hard without the flag
• Added Parser.sysctls unit tests (note: swift test needs full Xcode; I only had CLT locally, so tests are unrun locally — CI should cover)

Defaults are unchanged: without the flags, behavior is exactly 1.2.0.

[jglogan]

@ronandi Have you tried this sort of thing for sysctl:

--kernel-arg sysctl.net.ipv4.ip_forward=1

[ronandi]

Thank you for that @jglogan! --kernel-arg sysctl.net.ipv4.ip_forward=1 does work on 1.2.0 (verified: guest reads 1). That covers the sysctl half

I'm trying to run a kube cluster and kindest/node's entrypoint dies at mount -o remount,ro /sys with EPERM, and kernel args can't help there. With --privileged it boots cleanly (containerd + kubelet come up).

Use case, for context: running a long-lived local Kubernetes cluster on apple/container (kubeadm/k3s node images). Kubernetes nodes fundamentally need to write sysctls and remount /sys at boot, so 1.2.0's defaults make node images unbootable

[prskr]

I don't mean to hijack this discussion but how would that apply to container machines? From what I can tell the --kernel-arg flag is not exposed for any container machine sub-command but they're facing the same issue that /proc/sys is not writable and therefore - if you'd use a container machine for instance as a secure dev machine - parameters like fs.inotify.max_user_instances are quickly becoming a limitation for editors connecting remotely, let alone a Docker / Podman setup 🙈

[jglogan]

@ronandi Thanks for the contribution, but we're going to close it as we're working on getting a different fix out quickly for this one. We're not ready to a --privileged flag for container at this time; rather, we'll expose the fine grained controls for power users.

As a quick fix we're going to make the OCI path controls manageable as experimental CLI options that we'll deprecate once we can get a more general solution in place. We'll do a patch release at the end of the week that includes the fix.