Podman is not compatible with user management inside container (i.e. with libnss-extrausers)

[pboguslawski]

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

/kind bug

Description

(1)
One cannot force podman run --user=1234:1234 to avoid touching '/etc/passwd' when one uses own logic like extrausers...

https://packages.debian.org/bullseye/libnss-extrausers

...to create entry for UID 1234 in container entrypoint. Extrausers allows username to be resolved in container.

podman run should have option (maybe --no-userdb-changes to disable touching user/group db in container if admin prefers such solution.

(2)
If one try to run podman run --user usertest:usertest without usertest present in /etc/passwd in container - podman will throw Error: unable to find user usertest: no matching entries in passwd file error even if such user will be created by container itself (i.e. using extrausers).

podman run should have option (maybe --no-userdb-checks to disable checking for user/group existence in container if admin prefers such solution.

Output of podman version:

Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.9
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.6
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 2
  distribution:
    distribution: debian
    version: "11"
  eventLogger: journald
  hostname: [...]
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.10.0-8-amd64
  linkmode: dynamic
  memFree: 954667008
  memTotal: 4122234880
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: true
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    selinuxEnabled: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 2147479552
  swapTotal: 2147479552
  uptime: 3h 2m 9.09s (Approximately 0.12 days)
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 14
    paused: 0
    running: 14
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 16
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.9
  OsArch: linux/amd64
  Version: 3.0.1

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

# dpkg -s podman | grep Version
Version: 3.0.1+dfsg1-3+b2

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

No

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

[mheon]

I don't think we want to touch the defaults here. Would a new flag to disable alterations to /etc/passwd and /etc/groups work for you?

[pboguslawski]

I don't think we want to touch the defaults here. Would a new flag to disable alterations to /etc/passwd and /etc/groups work for you?

Yes, flag to disallow podman touching existing /etc/passwd and /etc/groups in container will resolve (1). What about same flag being more general (i.e. --own-userdb-mgmt) and disable checking also existence of username and group inside of container like in (2)?

[mheon]

That could have other effects - we need those checks to ensure your user in the container has the appropriate groups added.

[pboguslawski]

Ok. Flag to disable alterations to /etc/passwd and /etc/groups will resolve more important problem (1). Thank you.

[giuseppe]

If one try to run podman run --user usertest:usertest without usertest present in /etc/passwd in container - podman will throw Error: unable to find user usertest: no matching entries in passwd file error even if such user will be created by container itself (i.e. using extrausers).

I am not sure how this is supposed to work.

Podman needs to know the UID and GID before the container starts because it needs to set it in the OCI runtime configuration that expects two uint32 (https://github.com/opencontainers/runtime-spec/blob/master/schema/defs.json#L57-L62).

One suggestion, you could try to add the users with a prestart hook, and see if that would work.

[pboguslawski]

You quoted (2) - this was dropped already above.

I am not sure how this is supposed to work.

Resolution for problem (1): when new flag (i.e. --no-userdb-changes) is added to podman run podman should not touch /etc/passwd nor /etc/group in container. Docker (checked in Debian9) does not modify /etc/passwd nor /etc/group so podman should have option for compatibility.

One suggestion, you could try to add the users with a prestart hook, and see if that would work.

Seems overcomplicated for such simple thing + not sure if hooks are able to modify /etc/passwd when podman run is executed with --read-only and if podman modifies /etc/passwd after hooks are fired or before.

Consider adding such flag for compatibility with docker.

[mheon]

I'll reopen for the flag - maybe --no-manage-passwd

[pboguslawski]

--no-manage-passwd suggests it's for passwd only and podman modifies /etc/group also. Both shouldn't be touched when this flag is present.

[pboguslawski]

After rethinking: package for passwd/groups is also called passwd

https://packages.debian.org/bullseye/passwd

so --no-manage-passwd is ok IHMO.

[pboguslawski]

One more idea: when podman adds passwd entry, it hardocodes some stuff like home, comment, shell, username (=uid), groupname(=gid); would be better not only to allow to disable touching /etc/passwd and /etc/group but also allow admin to fine tune these entries it required; consider adding new parameter to podman run like

--user-passwd=auto (default, as now) | none (don't change /etc/passwd nor /etc/group) | username=user123,groupname=group123,comment="comment 123",shell=shell123 (allow to fine tune; absent options with auto values as now)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@cdoern PTAL

[cdoern]

actively working on this.