podman: The `--user` option has inconsistent effects on the container passwd and group entries.

Issue Description

I’ve discussed this with @cevich on IRC and he saw the same inconsistencies on his end.

The Podman documentation mentions Both user and group may be symbolic or numeric. for the --user option. This is also true for Docker where the documentation states Username or UID (format: <name|uid>[:<group|gid>]). Symbolic names don’t actually work for either Podman or Docker so there’s bug for bug consistency there.

What is different though is how /etc/{passwd,group} entries are handled. Docker doesn’t add entries at all and just sets the specified UID and GID. Meanwhile, Podman adds the specified UID to /etc/passwd with the same username as on the host but the group name of the entry created in /etc/group uses the GID itself rather than the group name on the host.

I don’t think there’s any reason for passwd and group entries to not be created inside the container based on the entries from the host if they don’t already exist in the image. I don’t see any scenario where a user must have a certain UID and GID but must not have a passwd and group entry. If the same UID and GID exist in both the host and the image, it’s probably best to not alter /etc/{passwd,group}.

Alternatively, the new --passwd-entry and --group-entry options can be used to add the entries independent of --user but the problem of what to do if there’s a collision with a UID and GID that already exists in the image remains.

As for symbolic names, the only reason I can see to retain the bug is if something out there relies on it to fail which seems a bit far-fetched.

The following script illustrates the behavior of the different combinations of the parameters of the --user option when executed. Use sudo to enable execution of the docker commands so that SUDO_UID and SUDO_GID are set.

#!/bin/bash

# Both Docker and Podman document accepting either
# numeric or symbolic parameters for `--user`.

USER_ID="${SUDO_UID:-$(id --user)}"
GROUP_ID="${SUDO_GID:-$(id --group)}"
USER_NAME="$(id --user --name ${USER_ID})"
GROUP_NAME="$(id --group --name ${GROUP_ID})"

IMAGE="${IMAGE:-docker.io/library/alpine:latest}"

COMMANDS="
    id;
    getent passwd ${USER_ID} || echo 'Passwd entry not found.';
    getent group ${GROUP_ID} || echo 'Group entry not found.';
"

function docker_user() {
    echo
    echo "# Docker: sets just the UID but doesn't create a passwd entry."
    docker run --rm --user "${USER_ID}" "${IMAGE}" sh -c "${COMMANDS}"
    echo
    echo "# Docker: sets the UID and GID but doesn't create a passwd and group entry."
    docker run --rm --user "${USER_ID}:${GROUP_ID}" "${IMAGE}" sh -c "${COMMANDS}"
    echo
    echo "# Docker: symbolic user names don't work contrary to documentation."
    docker run --rm --user "${USER_NAME}" "${IMAGE}" sh -c "${COMMANDS}"
    echo
    echo "# Docker: a combination of the UID and the group name doesn't work either."
    docker run --rm --user "${USER_ID}:${GROUP_NAME}" "${IMAGE}" sh -c "${COMMANDS}"
}

function podman_user() {
    echo
    echo "# Podman: sets only the UID and creates a passwd entry with the correct"
    echo "# username but uses the GID as the name for the group entry."
    podman run --rm --user "${USER_ID}" "${IMAGE}" sh -c "${COMMANDS}"
    echo
    echo "# Podman: sets both the UID and GID as well as creating a passwd entry with"
    echo "# the correct username but uses the GID as the name for the group entry."
    podman run --rm --user "${USER_ID}:${GROUP_ID}" "${IMAGE}" sh -c "${COMMANDS}"
    echo
    echo "# Podman: as with Docker, symbolic user names don't work."
    podman run --rm --user "${USER_NAME}" "${IMAGE}" sh -c "${COMMANDS}"
    echo
    echo "# Podman: as with Docker, a combination of the UID and the group name doesn't work."
    podman run --rm --user "${USER_ID}:${GROUP_NAME}" "${IMAGE}" sh -c "${COMMANDS}"
}

echo "USER_ID:USER_NAME = ${USER_ID}:${USER_NAME}"
echo "GROUP_ID:GROUP_NAME = ${GROUP_ID}:${GROUP_NAME}"

[[ $EUID -eq 0 ]] && docker_user
podman_user

Steps to reproduce the issue

Steps to reproduce the issue

  1. Run the script above to illustrate the behavior of the different combinations of the parameters for the --user option.

Describe the results you received

On my system, the script outputs the following:

USER_ID:USER_NAME = 1000:core
GROUP_ID:GROUP_NAME = 1000:core

# Docker: sets just the UID but doesn't create a passwd entry.
uid=1000 gid=0(root) groups=0(root)
Passwd entry not found.
Group entry not found.

# Docker: sets the UID and GID but doesn't create a passwd and group entry.
uid=1000 gid=1000 groups=1000
Passwd entry not found.
Group entry not found.

# Docker: symbolic user names don't work contrary to documentation.
docker: Error response from daemon: unable to find user core: no matching entries in passwd file.

# Docker: a combination of the UID and the group name doesn't work either.
docker: Error response from daemon: unable to find group core: no matching entries in group file.

# Podman: sets only the UID and creates a passwd entry with the correct
# username but uses the GID as the name for the group entry.
uid=1000(core) gid=0(root) groups=0(root)
core:*:1000:0:CoreOS Admin:/:/bin/sh
1000:x:1000:1000

# Podman: sets both the UID and GID as well as creating a passwd entry with
# the correct username but uses the GID as the name for the group entry.
uid=1000(core) gid=1000(1000) groups=1000(1000)
core:*:1000:1000:CoreOS Admin:/:/bin/sh
1000:x:1000:1000

# Podman: as with Docker, symbolic user names don't work.
Error: unable to find user core: no matching entries in passwd file

# Podman: as with Docker, a combination of the UID and the group name doesn't work.
Error: unable to find group core: no matching entries in group file

Describe the results you expected

Ideally, --user should just add passwd and group entries with the names from the host to the container if they don’t already exist, whether specified numerically or symbolically.

podman info output

version:
  APIVersion: 4.5.0
  Built: 1681486942
  BuiltTime: Fri Apr 14 15:42:22 2023
  GitCommit: ""
  GoVersion: go1.20.2
  Os: linux
  OsArch: linux/amd64
  Version: 4.5.0

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional information

Updated the script to use a combination of the UID and the group name since it’s pointless to test a combination of the user and group names when it already fails on just the user name.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 18 (6 by maintainers)

Most upvoted comments

Cross-posting my comment from https://github.com/containers/podman/issues/18902:

Perhaps we should bring the `--group-entry` and `--user` oddities to a community
cabal and see if we can arrive at a better direction to take them, maybe for
5.0?

Though after reading Paul’s comment above, I’d consider just including all the related options as well. Basically all options that let the user control UID/GID in the container at runtime, along with manipulating /etc/passwd and /etc/group.

I’m thinking maybe this should be an RFE. But I’ll let others comment.

See also the slightly related: https://github.com/containers/podman/issues/18902