Cannot login as user from "generateCurrentUserPasswdEntry"

[njam]

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

/kind bug

Description

Since 2.0.5 podman creates a user account when --userns=keep-id is set. I experience problems using that account in the container. I think it might be caused by an invalid entry in /etc/passwd.

Steps to reproduce the issue:

1. Start a debian container, and try to run a command as the "keep-id"-user

podman run --rm -it --user=root --userns=keep-id debian:10 su $(whoami) -c whoami

Describe the results you received:
Command fails with this error: "su: Authentication failure"

Describe the results you expected:
No error.

Additional information you deem important (e.g. issue happens only occasionally):
Podman adds the following line to /etc/passwd:

USER:x:1000:995:USER:/:/bin/sh

As far as I understand the password value "x" indicates that the password for this user can be found in the file /etc/shadow, but that file doesn't contain any entry for this user.
If I change the password value from "x" to "*" (no password), then I can log in and use the user account normally.

This functionality was added in 3dfd863 cc @rhatdan @vrothberg

Output of podman version:

Version:      2.0.5
API Version:  1
Go Version:   go1.15
Git Commit:   776abc52106ec7652ced6dbc0869020123ed393d
Built:        Tue Aug 25 20:58:48 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.1
  cgroupVersion: v1
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.20, commit: 13244db638cf987c415298a3c23393ae5abeb885'
  cpus: 12
  distribution:
    distribution: arch
    version: unknown
  eventLogger: file
  hostname: njamdesk
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 995
      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.5-arch1-1
  linkmode: dynamic
  memFree: 5362950144
  memTotal: 33520361472
  ociRuntime:
    name: runc
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc92
      commit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
      spec: 1.0.2-dev
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.1.4
      commit: b66ffa8e262507e37fca689822d23430f3357fe8
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 0
  swapTotal: 0
  uptime: 5h 45m 58.77s (Approximately 0.21 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  configFile: /home/reto/.config/containers/storage.conf
  containerStore:
    number: 29
    paused: 0
    running: 3
    stopped: 26
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: Unknown
      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: /home/reto/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 95
  runRoot: /run/user/1000/containers
  volumePath: /home/reto/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1598381928
  BuiltTime: Tue Aug 25 20:58:48 2020
  GitCommit: 776abc52106ec7652ced6dbc0869020123ed393d
  GoVersion: go1.15
  OsArch: linux/amd64
  Version: 2.0.5

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

$ pacman -Q podman       
podman 2.0.5-1

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.):

physical

[njam]

Update: Below comment was extraced to a separate ticket: #7503

---

Another problem regarding generateCurrentUserPasswdEntry() seems to me that it will add a user account with an already existing UID.

For example the quay.io/podman/stable image already has a user account with UID 1000 ("podman"). When I run a container with that image, podman will create a second user with UID 1000 named after my host user.

$ id -u
1000
$ podman run --rm -it --user=root --userns=keep-id quay.io/podman/stable tail -n2 /etc/passwd
podman:x:1000:1000::/home/podman:/bin/bash
USER:x:1000:995:USER:/:/bin/sh

[mheon]

Second one is a separate, more serious bug - please file a new issue for it.

[mheon]

For the first one - @rhatdan Thoughts?

[rhatdan]

The /etc/passwd entry seems correct.

[mheon]

@rhatdan Sure, but we're not messing with /etc/shadow (and I really don't want to do that) so we're creating a user that claims it has a password, but actually does not. This breaks the ability to log in as the user in the container, which is relevant to pet container use-cases like Toolbox (I can also definitely see systemd-in-a-container as rootless wanting to do this).

[rhatdan]

Not sure what you mean by logging into the user. Seems to me we have 4 possible values to stick in this field.

"" - Dangerous because no password required to become user
* - Indicates not a login user, and no entry in /etc/shadow (Problem is some programs like su on debian complain)
x - Indicates a login user, but we are supposed to have an entry in /etc/shadow, which we don't want to have
RANDOM - Indicates a login user, we generate a random password, that translates to nothing.  Possibility that this could be guessable, I guess.
FixedPassword - Similar problem to "", in that tools could easily become this user.

[mheon]

Initial decision from the team: we're going to set * instead of x which should allow login via su

[mheon]

I'll take this one