Rootless container starts with root user

[dmenneck]

Issue Description

I am currently working on the networking tutorial https://github.com/containers/podman/blob/main/docs/tutorials/basic_networking.md which runs a rootless web server.
However, when I start the container, the user in the container is root.

Steps to reproduce the issue

Steps to reproduce the issue

1. podman run -dt --name webserver -p 8080:80 quay.io/libpod/banner
2. podman exec -it webserver sh
3. whoami
4. id

Describe the results you received

The whoami command returns root and id shows that the root user is in the following groups

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

Describe the results you expected

I had thought that the user in a rootless container is unprivileged and therefore not root. Is something wrong with my setup or is it indeed intented that the user is root?

podman info output

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 16
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: mennecke
  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.15.90.1-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 13773639680
  memTotal: 16362266624
  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/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 4294967296
  swapTotal: 4294967296
  uptime: 51m 42.34s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/dmenneck/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/dmenneck/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 8
  runRoot: /run/user/1000/containers
  volumePath: /home/dmenneck/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.18.1
  OsArch: linux/amd64
  Version: 3.4.4

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[vrothberg]

Thanks for reaching out, @dmenneck!

I had thought that the user in a rootless container is unprivileged and therefore not root. Is something wrong with my setup or is it indeed intented that the user is root?

The "rootless" relates to the user creating/running the container/Podman. Inside the container's user namespace, the processes can get any UID/GID including root. By default, the user inside the container is set to root. The reasoning behind that is portability: many tools such as package managers and web server want to run as root and would otherwise break.

[dmenneck]

Thank you for the explanation, @vrothberg!

I noticed that Dockerhubs-based postgres image (docker.io/library/postgres:15.3) starts with the root user, while Red Hats Repository-based postgres image (registry.redhat.io/rhel8/postgresql-15) starts with the postgres user, who is in the root group. So which image is "more secure"? Is it possible to use an unprivileged user inside the postgres container?

[rhatdan]

Starting with the non root user would be more secure in general.

Images can embed the user that they want to start with and Podman and Docker follow the rules set in the image. If the image does not set anything, then it defaults to root.