The problem
When running a dev container with rootless podman, the Dev Containers CLI injects a plain --userns=keep-id flag, which maps the host user in at the same UID number inside the container.
This only produces a seamless mapping when the container's user happens to share the host user's UID. It breaks for high/out-of-range host UIDs (e.g. AD/SSSD users which have values like1400601154, where the container's vscode user at UID 1000 is a different user than the mapped host user, causing Permission denied on the workspace bind mount) and would break any hardcoded default for images that bake their user to a non-1000 UID.
Current workaround
The current workaround is a fragile manual runArgs entry (--userns=keep-id:uid=1000,gid=1000). This allows me to use podman on Linux boxes with AD and thus high uid/gid combinations.
The request for improvement
Instead of injecting a plain --userns=keep-id, the CLI should resolve the remoteUser's actual UID/GID in the image and emit --userns=keep-id:uid=<remote-uid>,gid=<remote-gid>. This fixes the high-UID case with no regressions: when the host UID already equals the container user's UID, keep-id:uid=X,gid=X produces the identical mapping to plain keep-id, so existing setups are unaffected.
The problem
When running a dev container with rootless podman, the Dev Containers CLI injects a plain
--userns=keep-idflag, which maps the host user in at the same UID number inside the container.This only produces a seamless mapping when the container's user happens to share the host user's UID. It breaks for high/out-of-range host UIDs (e.g. AD/SSSD users which have values like
1400601154, where the container'svscodeuser at UID 1000 is a different user than the mapped host user, causingPermission deniedon the workspace bind mount) and would break any hardcoded default for images that bake their user to a non-1000 UID.Current workaround
The current workaround is a fragile manual
runArgsentry (--userns=keep-id:uid=1000,gid=1000). This allows me to use podman on Linux boxes with AD and thus high uid/gid combinations.The request for improvement
Instead of injecting a plain
--userns=keep-id, the CLI should resolve theremoteUser's actual UID/GID in the image and emit--userns=keep-id:uid=<remote-uid>,gid=<remote-gid>. This fixes the high-UID case with no regressions: when the host UID already equals the container user's UID,keep-id:uid=X,gid=Xproduces the identical mapping to plainkeep-id, so existing setups are unaffected.