Podman --rootfs path permissions, with permissions attached to --group-add group while using --uidmap/gidmap.

[KCSesh]

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

/kind bug

Description

I am attempting to create a container using the --rootfs option with unprivileged users.

I am trying to lock down the permissions to the actual rootfs to specific groups.

For example my rootfs path:
/data/storage/only-group-common/rootfs

I only want groupCommon to have access.
I use ACL permissions to make sure only groupCommon has access.

For simplicity here are the users and groups at play:

user1 - 1000
group1 - 1000
groupCommon - 1005

When I start my container I am using the following command:

sudo podman --storage-driver vfs --root /data/podman/root --runroot /data/podman/run create --name test --read-only --uidmap 0:1000:1 --uidmap  1:100000:65536 --gidmap 0:1000:1 --gidmap 1:100000:65536 --gidmap 100000:1005:1 --group-add 100000 -it --rootfs /data/storage/only-group-common/rootfs /bin/bash

This fails because only group 1005 has access to the rootfs.
If I add access to group 1000 to the rootfs path of /data/storage/only-group-common, the container can start.

I am wondering if this is expected behavior?

I imagine that the group-add option happens after the podman attempts to access the rootfs?
I am wondering if I can get a better understanding on what happens here?
Is it possible to have the group-add step occur before podman accesses the rootfs?

Steps to reproduce the issue:

sudo podman --storage-driver vfs --root /data/podman/root --runroot /data/podman/run create --name test --read-only --uidmap 0:1000:1 --uidmap  1:100000:65536 --gidmap 0:1000:1 --gidmap 1:100000:65536 --gidmap 100000:1005:1 --group-add 100000 -it --rootfs /data/storage/groupCommon/rootfs /bin/bash

setfacl -Rm -o::x /data/podman

sudo podman --storage-driver vfs --root /data/podman/root --runroot /data/podman/run start -ia test

Describe the results you received:

Error: unable to start container 320250fe6e66db9d7fac4fb35de3adc82d64a52c2ef656b5faa5901d851f371d: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"rootfs_linux.go:46: preparing rootfs caused \\\"permission denied\\\"\"": OCI permission denied

Describe the results you expected:

Ideally I want the container to be able to start.

podman info --debug

host:
  arch: arm64
  buildahVersion: 1.21.1
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  - debug
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/local/bin/conmon'
    path: /usr/local/bin/conmon
    version: 'conmon version 2.0.29-dev, commit: '
  cpus: 8
  distribution:
    distribution: ubuntu
    version: "18.04"
  eventLogger: file
  hostname: ubuntu
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 4.9.140
  linkmode: dynamic
  memFree: 8351485952
  memTotal: 16451817472
  ociRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 8225882112
  swapTotal: 8225882112
  uptime: 99h 31m 23.47s (Approximately 4.12 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /data/podman/root
  graphStatus: {}
  imageStore:
    number: 0
  runRoot: /data/podman/run
  volumePath: /data/podman/root/volumes
version:
  APIVersion: 3.3.0-dev
  Built: 1623343160
  BuiltTime: Thu Jun 10 16:39:20 2021
  GitCommit: dffbf16b24ba971a96db753100b7f43f5d6df3f8
  GoVersion: go1.16
  OsArch: linux/arm64
  Version: 3.3.0-dev

[mheon]

This sounds expected, because --group-add happens very late in the container creation process, and Podman needs access to the rootfs prior to configuring the container user (for example, we need to read /etc/passwd and /etc/group to determine other groups the container user should be added to).

[KCSesh]

Okay this makes sense.

I think I just wanted that confirmation that this is expected.

[rhatdan]

@mheon is this something we can fix, or should we close the issue?

[mheon]

I don't think this is fixable - Podman needs a certain level of privileges to do its job of creating containers, including full access to the container rootfs (whether it's an OCI image we've mounted or a user-created directory).

[rhatdan]

Theoretically you could mount a overlay fs on top and as long as the lower has read access, then we could share the rootfs.