Feature request: derive `--userns=keep-id` mapping from the remote user's actual UID/GID

[karypid]

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 id to the same UID number inside the container.

This breaks for high/out-of-range host UIDs (e.g. AD/SSSD users which have values like1400601154, which are not valid inside the container (they are out of range as the containers are typically given a 0-65535 range via subuid/subgid mapping). As a result the mapping fails silently and the container's vscode user remains at UID 1000, not matching the host user, and causing Permission denied on the workspace bind mount).

Current workaround

The current workaround is a fragile manual runArgs entry (--userns=keep-id:uid=1000,gid=1000). Since the host UID is unmappable to itself, we keep the 1000 id inside the container and map the host user to that. This allows one to use podman on Linux boxes with AD and thus high uid/gid combinations, as it removes the requirement for the exact host UID to be inside the container's range.

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.

[karypid]

Hello,

The combination of these PRs allows "defaults" to work for cases where the host UID/GID is abnormally high. This is common when the Linux workstation is using Active Directory for authentication (e.g. via SSSD or FreeIPA). In this case a base value is used to avoid clashing with regular users so UID/GID in the billions is possible.

If you use a regular devcontainer.json and the CLI detects podman, it injects these defaults:

  "runArgs": [
    "--userns=keep-id",      // user has not specified, but CLI injects this for podman
  ],

The problem is that typically in /etc/login.def users are allowed to map up 64K IDs:

# Extra per user uids
SUB_UID_MIN        524288
SUB_UID_MAX     600100000
SUB_UID_COUNT           65536

Therefore the above fails because if your host UID is >64K it is out of range inside the container.

In order to use rootless podman in a system that has a high UID/GID (common when the Linux workstation is using Active Directory for authentication, e.g. via SSSD or FreeIPA) you need to specify special flags that address this:

  "runArgs": [
    "--userns=keep-id:uid=1000,gid=1000", // map to a container user  that is within range: <64K
  ],
  "updateRemoteUserUID": false, // do not attempt to chown the workspace to match host UID/GID as it fails (out of range >64K)

However, making such changes to devcontainer.json will make it break for other users that have "normal" UID/GID (typically starting at 1000 in most Linux distros).

This fix detects this situation for podman and applies the configuration that works:

  "runArgs": [
    "--userns=keep-id:uid=...,gid=...",   // actual values are detected from container settings for remoteUser
  ],
  "updateRemoteUserUID": false,  // since user is owned by target mapping no need to chown to host UID/GID

Therefore a devcontainer.json that does not specify a --userns run argument and has no updateRemoteUserUID can work for the cases of high UID/GID - existing docker/podman users are unaffected as these defaults only kick in when the UID is unmappable. Therefore a devcontainer.json with defaults will work in all cases.

Let me know if you need further clarification.