DevSpaces image: duplicate /etc/passwd entries and /var write permissions

[leogallego]

Summary

The ansible-devspaces container image has two runtime issues when deployed on OpenShift Dev Spaces:

1. Duplicate /etc/passwd entries for user due to OpenShift UID injection conflicting with the image's existing entry
2. /var subdirectories are not writable, preventing runtime package installation and some tool operations

Issue 1: Duplicate /etc/passwd entries

Background

PR #735 fixed the original UID mismatch by removing the injected user at UID 10001 and recreating it at UID 1000. This fix is confirmed in ghcr.io/ansible/ansible-devspaces:v26.4.5.

Remaining problem

At runtime on OpenShift, the CRI-O runtime injects a second passwd entry when the SCC assigns a UID from the namespace range:

user:x:1000:1000::/home/user:/bin/bash
user:x:1000860000:0:user user:/home/user:/bin/bash

This creates ambiguity:

• getent passwd user returns UID 1000, but the process runs as UID 1000860000
• id shows uid=1000860000(user) but passwd lookups by name resolve to UID 1000
• Potential issues with file ownership checks, terminal environment setup, and shell spawning

Possible fixes

1. Don't create user in the image — let OpenShift's runtime injection be the sole entry (may break non-OpenShift use)
2. Use a different username in the image (e.g., developer) to avoid collision with runtime injection
3. Accept the duplicate and ensure tooling handles it gracefully

Issue 2: /var subdirectories not writable

/var/lib, /var/cache, and other subdirectories under /var are not writable by the runtime user. This prevents:

• dnf install for new packages at runtime (e.g., pinentry-curses needed for GPG signing with ansible-sign)
• Package manager cache operations

While /usr/bin being read-only is expected for container immutability, /var is traditionally writable for package manager state and caches.

Current workaround

For Python packages, pip install into the .venv works (e.g., pip install cowsay). For system packages that have no pip equivalent, users must bake them into the image.

Suggested fix

Ensure /var/lib/dnf, /var/cache/dnf, and /var/log/dnf are writable by the runtime user, or provide a mechanism to install additional system packages at workspace startup (e.g., via devfile postStart commands with appropriate permissions).

Environment

• OpenShift 4.21.9
• Red Hat OpenShift Dev Spaces 3.27
• che-code 1.104.3
• Image: ghcr.io/ansible/ansible-devspaces:v26.4.5
• Base: RHEL 9 UBI
• ansible-dev-tools 26.4.5, ansible-core 2.20.5

Related upstream issues and PRs

• fix: devspaces sudo support with correct UID and user setup #735 — fix: devspaces sudo support with correct UID and user setup (merged)
• fix: add runtime user to wheel group for passwordless sudo in devspaces #730 — fix: add runtime user to wheel group for passwordless sudo (merged)
• fix: devspaces rootless podman, sudo, prompt hostname, and EE example #728 — fix: devspaces rootless podman, sudo, prompt hostname, and EE example (merged)
• fix: devspaces passwordless sudo not working — user not added to wheel group #729 — fix: devspaces passwordless sudo not working (closed)
• BUG: Devcontainer running in Docker does not set UID #376 — BUG: Devcontainer running in Docker does not set UID (open)
• Add RPM pinentry #552 — Add RPM pinentry (merged — pinentry is now baked in, but dnf install for other packages still blocked by /var permissions)

Downstream tracking

• rhpds/ansible-dev-tools-workspace#10