Permission denied accessing container files when running in rootless mode with userns=keep-id

[zyzhu2000]

Issue Description

1. When the home directory has permission 700, running rootless podman with userns=keep-id causes a permission denied error.
2. When the home directory has permission 701, running rootless podman with userns=keep-id works fine.
3. When the home directory has permission 700, running rootless podman with userns=nomap silently changes the permission of my home directory to 711.

Steps to reproduce the issue

Everything is done under my user id, which does not have root privilege.

Now, I run the following on the host:

1. podman pull docker.io/library/debian:latest
2. chmod 700 ~
3. podman run -it --rm --userns=keep-id debian bash

I immediately get the following output:

Error: crun: make `/[redacted]/storage/overlay/4bbf7ee52463d3fc8f3b237c4334910c9b508c6ddb439e98f64740c14aad28b7/merged` private: Permission denied: OCI permission denied

Now, if I do the following on the host:

1. chmod 701 ~.
2. Run this again: podman run -it --rm --userns=keep-id debian bash

Everything works as expected. So it looks like userns=keep-id needs the home directory to have permission 701.

Now, let's do the following:

1. chmod 700 ~
2. podman run -it --rm --userns=nomap debian bash

Everything runs correctly, but if I run the following on the host:

stat -c %a ~
711

It looks like running podman with userns=nomap changes my home directory's permission to 711 silently.

Describe the results you received

1. When home directory has permission 700, running podman with userns=keep-id causes a permission denied error.
2. When home directory has permission 701, running podman with userns=keep-id works correctly.
3. When home directory has permission 700, running podman with userns=nomao works correctly but automatically changes the permission of my home directory to 711.

Describe the results you expected

1. I expect to be able to run rootless podman with userns=keep-id with home directory permission 700
2. I expect to be able to run rootless podman with userns=nomap without it silently changing my home directory permission to 711.

podman info output

## podman version

Client:       Podman Engine
Version:      4.3.1
API Version:  4.3.1
Go Version:   go1.19.8
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64 

## podman info
host:
  arch: amd64
  buildahVersion: 1.28.2
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.6+ds1-1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: unknown'
  cpuUtilization:
    idlePercent: 92.12
    systemPercent: 2.15
    userPercent: 5.72
  cpus: 40
  distribution:
    codename: bookworm
    distribution: debian
    version: "12"
  eventLogger: journald
  hostname: ma
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 500
      size: 1
    - container_id: 1
      host_id: 4425376
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1234
      size: 1
    - container_id: 1
      host_id: 4425376
      size: 65536
  kernel: 6.1.0-22-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 46478913536
  memTotal: 405704052736
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun_1.8.1-1+deb12u1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.1
      commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
      rundir: /run/user/1234/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1234/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_1.2.0-1_amd64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 0
  swapTotal: 1023406080
  uptime: 5031h 13m 19.00s (Approximately 209.62 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /[redacted]/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /[redacted]//var/storage
  graphRootAllocated: 111553035689984
  graphRootUsed: 55811689517056
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1234/containers
  volumePath: /[redacted]/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.19.8
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

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

Update

On reflection, this may be the expected behavior. In the rootless mode with userns=keep-id, my host user id is mapped to a container user of the same uid. This means the container root user has to be mapped to some subuid on the host. In order for the container root to have access to the container files residing on the host, it will need at least directory traversal permission for every directory from "/" to the files, and this is why the 001 bit is set. I am unsure about the internal implementation., This is my deduction by logic. Is there a better/safer way to get my things set up? If not, you can close it.

[Luap99]

We only support the latest version upstream. I am pretty sure this has been fixed in 5.2/5.3 by using the mount API.