userns=keep-id and anonymous volumes

[canon-cmre-benoit-lecardonnel]

Issue Description

Hello,

I'm observing a difference of behaviour between podman 4.9.4 and podman 5.2.2 when using --userns=keep-id and anonymous volumes for existing directories.
It seems the owner of the volume root directory differs between these 2 version. I think the 4.9.4 behaviour is the expected one.

This happens when all the following are met:

• Use --userns=keep-id
• Mount an anonymous volume
• The anonymous volume is mounted on top of a directory that already exists in the container image

I'm also running rootless. I do not know if that happens with rootful.

Steps to reproduce the issue

Steps to reproduce the issue

1. Setup podman rootless (subuid and subgid)
2. Execute e.g.
   [user@host ~]$ podman run --userns=keep-id:uid=1001,gid=1001 --rm -v /opt/app-root/etc/nginx.default.d registry.access.redhat.com/ubi9/nginx-122 ls -ld /opt/app-root/etc/nginx.default.d

Describe the results you received

drwxrwxr-x. 2 1000 1001 6 Nov  3 01:00 /opt/app-root/etc/nginx.default.d

So the directory is owned by UID 1000 and GID 1001.

Describe the results you expected

drwxrwxr-x. 2 default root 6 Nov  3 01:00 /opt/app-root/etc/nginx.default.d

In other words, I expect the root directory of the anonymous volume to use the same ownership info as the directory in the container image.

podman info output

host:
  arch: amd64
  buildahVersion: 1.37.5
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.12-1.el9.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: c0564282e9befb7804c3642230f8e94f1b2ba9f8'
  cpuUtilization:
    idlePercent: 99.6
    systemPercent: 0.15
    userPercent: 0.25
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: rhel
    version: "9.4"
  eventLogger: journald
  freeLocks: 2048
  hostname: plain-gull-5
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.14.0-427.40.1.el9_4.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 282755072
  memTotal: 3836878848
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.12.1-1.el9.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.12.1
    package: netavark-1.12.2-1.el9.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.12.2
  ociRuntime:
    name: crun
    package: crun-1.16.1-1.el9.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.16.1
      commit: afa829ca0122bd5e1d67f1f38e6cc348027e3c32
      rundir: /run/user/1001/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20240806.gee36266-2.el9.x86_64
    version: |
      pasta 0^20240806.gee36266-2.el9.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: false
    path: /run/user/1001/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.1-1.el9.x86_64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 8581754880
  swapTotal: 8589930496
  uptime: 11h 5m 13.00s (Approximately 0.46 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/ansible/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/ansible/.local/share/containers/storage
  graphRootAllocated: 62262345728
  graphRootUsed: 9775775744
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 5
  runRoot: /run/user/1001/containers
  transientStore: false
  volumePath: /home/ansible/.local/share/containers/storage/volumes
version:
  APIVersion: 5.2.2
  Built: 1729674539
  BuiltTime: Wed Oct 23 09:08:59 2024
  GitCommit: ""
  GoVersion: go1.22.7 (Red Hat 1.22.7-2.el9_5)
  Os: linux
  OsArch: linux/amd64
  Version: 5.2.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Running on RHEL9, podman package version: 4:5.2.2-9.el9_5 (which seems to be the latest).

Additional information

Older podman versions, such as 4.9.4-rhel, provide the expected behaviour, so this seems like a regression in 5.2.2.

Newer podman versions, such as 5.3.0-dev-8f2d5011f, provide the expected behaviour as well.
I do not know exactly what change between 5.2.2. and 5.3.0 fixes the problem, but if you can identify it, can you backport it to the v5.2-rhel branch?

[Luap99]

Thanks for checking that this works with the latest version but we (upstream) only support the latest version.

If you need this fixed in RHEL you must contact Red Hat support and report this bug there in order for such fix to be backported.

[giuseppe]

this is a duplicate of: #23347