userns=keep-id creates unnamed user group #7389

HarryMichal · 2020-08-20T10:48:53Z

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Container created with option --userns=keep-id gets the current user with the correct UID and GUID but the group does not have the user's name.

More info from the Toolbox realm: containers/toolbox#523

Steps to reproduce the issue:

podman run --rm --userns=keep-id alpine id

Describe the results you received:

uid=1000(omichal) gid=1000

Describe the results you expected:

uid=1000(omichal) gid=1000(omichal)

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:      2.1.0-dev
API Version:  1
Go Version:   go1.15rc2
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.0-dev
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.21-0.3.dev.git5a6b2ac.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.21-dev, commit: 5c03a23398b94cf869f071128631ef7fd9153b3b'
  cpus: 8
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: file
  hostname: harry-work
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.8.0-1.fc33.x86_64
  linkmode: dynamic
  memFree: 4838907904
  memTotal: 16656273408
  ociRuntime:
    name: crun
    package: crun-0.14.1-2.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.14.1
      commit: 598ea5e192ca12d4f6378217d3ab1415efeddefa
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.4-4.dev.giteecccdb.fc33.x86_64
    version: |-
      slirp4netns version 1.1.4+dev
      commit: eecccdb96f587b11d7764556ffacfeaffe4b6e11
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 12363067392
  swapTotal: 12708732928
  uptime: 46h 1m 14.24s (Approximately 1.92 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /var/home/omichal/.config/containers/storage.conf
  containerStore:
    number: 13
    paused: 0
    running: 2
    stopped: 11
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.1.0-11.dev.git800011b.fc33.x86_64
      Version: |-
        fusermount3 version: 3.9.3
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.9.3
        using FUSE kernel interface version 7.31
  graphRoot: /var/home/omichal/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 11
  runRoot: /run/user/1000/containers
  volumePath: /var/home/omichal/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.15rc2
  OsArch: linux/amd64
  Version: 2.1.0-dev

Package info (e.g. output of rpm -q podman or apt list podman):

podman-2.1.0-0.169.dev.git162625f.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

Fedora Silverblue Rawhide (Rawhide.20200811.n.0)

The text was updated successfully, but these errors were encountered:

giuseppe · 2020-08-21T13:40:21Z

we'd have to create and manage /etc/group as well.

Isn't /etc bind mounted from the host on toolbox?

HarryMichal · 2020-08-22T13:50:54Z

Hi @giuseppe!

Toolbox bind mounts /etc to /run/host/etc.

debarshiray · 2020-08-28T16:56:59Z

What's the way forward here?

Recently, --userns=keepid started actually creating the user, but apparently not the group.

Is it a mistake that it creates the user, or that it doesn't create the group?

mheon · 2020-08-28T17:09:32Z

The code to add the user is deliberate, but we did not make the code alter /etc/group as well, so we'll probably need to do that as well.

Since Podman 2.0.5, containers that were created with 'podman create --userns=keep-id ...' automatically get the user added to /etc/passwd [1]. However, this user isn't as fully configured as it needs to be. The home directory is specified as '/' and the shell is /bin/sh. Note that Podman doesn't add the user's login group to /etc/group [2]. This leads to the following error when entering the container: /usr/bin/id: cannot find name for group ID 1000 It's expected that this will be fixed in Podman itself. Therefore, the entry point needs to call usermod(8) to update the user, instead of using useradd(8) to create it. [1] Podman commit 6c6670f12a3e6b91 containers/podman#6829 [2] containers/podman#7389 containers#523

Since Podman 2.0.5, containers that were created with 'podman create --userns=keep-id ...' automatically get the user added to /etc/passwd [1]. However, this user isn't as fully configured as it needs to be. The home directory is specified as '/' and the shell is /bin/sh. Note that Podman doesn't add the user's login group to /etc/group [2]. This leads to the following error message when entering the container: /usr/bin/id: cannot find name for group ID 1000 It's expected that this will be fixed in Podman itself. Therefore, the entry point needs to call usermod(8) to update the user, instead of using useradd(8) to create it. [1] Podman commit 6c6670f12a3e6b91 containers/podman#6829 [2] containers/podman#7389 containers#523

debarshiray · 2020-08-30T20:48:55Z

Now that Podman 2.0.5 has made it into Fedora 32, we really need to fix this. Otherwise this warning will begin to bother people every time they podman exec into a container:

/usr/bin/id: cannot find name for group ID 1000

To ensure that the user running in the container ahs a valid entry in /etc/passwd so lookup functions for the current user will not error, Podman previously began adding entries to the passwd file. We did not, however, add entries to the group file, and this created problems - our passwd entries included the group the user is in, but said group might not exist. The solution is to mirror our logic for /etc/passwd modifications to also edit /etc/group in the container. Unfortunately, this is not a catch-all solution. Our logic here is only advanced enough to *add* to the group file - so if the group already exists but we add a user not a part of it, we will not modify that existing entry, and things remain inconsistent. We can look into adding this later if we absolutely need to, but it would involve adding significant complexity to this already massively complicated function. While we're here, address an edge case where Podman could add a user or group whose UID overlapped with an existing user or group. Also, let's make users able to log into users we added. Instead of generating user entries with an 'x' in the password field, indicating they have an entry in /etc/shadow, generate a '*' indicating the user has no password but can be logged into by other means e.g. ssh key, su. Fixes containers#7503 Fixes containers#7389 Fixes containers#7499 Signed-off-by: Matthew Heon <[email protected]>

rhatdan · 2020-09-10T21:04:33Z

This PR is merged.

openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Aug 20, 2020

HarryMichal mentioned this issue Aug 20, 2020

sudo(8) inside toolbox containers asks for a password with Podman 2.0.5 containers/toolbox#523

Closed

rhatdan assigned mheon Aug 20, 2020

debarshiray mentioned this issue Aug 21, 2020

build: Ensure binaries built on Fedora 33 run on Fedoras 32 & 31 containers/toolbox#534

Merged

debarshiray mentioned this issue Aug 30, 2020

Unbreak 'sudo' inside toolbox containers with Podman 2.0.5 containers/toolbox#547

Merged

mheon mentioned this issue Sep 4, 2020

Make an entry in /etc/group when we modify /etc/passwd #7541

Merged

HarryMichal mentioned this issue Sep 9, 2020

cannot find name for group ID 1000 containers/toolbox#549

Closed

rhatdan closed this as completed Sep 10, 2020

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

userns=keep-id creates unnamed user group #7389

userns=keep-id creates unnamed user group #7389

HarryMichal commented Aug 20, 2020 •

edited

Loading

giuseppe commented Aug 21, 2020

HarryMichal commented Aug 22, 2020

debarshiray commented Aug 28, 2020

mheon commented Aug 28, 2020

debarshiray commented Aug 30, 2020

rhatdan commented Sep 10, 2020

userns=keep-id creates unnamed user group #7389

userns=keep-id creates unnamed user group #7389

Comments

HarryMichal commented Aug 20, 2020 • edited Loading

giuseppe commented Aug 21, 2020

HarryMichal commented Aug 22, 2020

debarshiray commented Aug 28, 2020

mheon commented Aug 28, 2020

debarshiray commented Aug 30, 2020

rhatdan commented Sep 10, 2020

HarryMichal commented Aug 20, 2020 •

edited

Loading