Cannot give secret to container running in user namespace

[exploide]

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

/kind bug

Description

I cannot give a secret (via file) to a container that shall be executed in a new user namespace. The steps to reproduce are executed as root.

Steps to reproduce the issue:

1. printf my-test-secret | podman secret create my_secret -

2. podman run --rm -it --secret my_secret --userns=auto alpine cat /run/secrets/my_secret

Describe the results you received:

podman run errors out with

Error: error stat'ing file /var/lib/containers/storage/overlay-containers/8a1868630625444cf7649c4fed82c3d5ca4c5551c431ef146f535301b0a55538/userdata/secrets/my_secret: Permission denied: OCI permission denied

Describe the results you expected:

I expected the secret mechanism to work with containers running in user namespaces.

Additional information you deem important (e.g. issue happens only occasionally):

Passing the secret via an environment variable works.

SELinux is enabled but the problem persists also after setenforce 0.

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.16.8
Built:        Wed Dec  8 22:45:07 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.30-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.30, commit: '
  cpus: 2
  distribution:
    distribution: fedora
    variant: server
    version: "35"
  eventLogger: journald
  hostname: fury
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.12-200.fc35.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 2323709952
  memTotal: 3047047168
  ociRuntime:
    name: crun
    package: crun-1.4-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4
      commit: 3daded072ef008ef0840e8eccb0b52a7efbd165d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/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: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 3046109184
  swapTotal: 3046109184
  uptime: 20m 10.01s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 3
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 1638999907
  BuiltTime: Wed Dec  8 22:45:07 2021
  GitCommit: ""
  GoVersion: go1.16.8
  OsArch: linux/amd64
  Version: 3.4.4

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

podman-3.4.4-1.fc35.x86_64

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)

Yes

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

Runs in a QEMU/KVM virtual machine.

[rhatdan]

@ashley-cui @vrothberg @giuseppe this is an interesting problem. Should secrets be stored as world readable? If they are not,does that mean only Root within a container can use the secret?

If secrets are per container, then we are already copying and this can be fixed by copying to the root of the user namespace.

If not then should we make copies if the secret is in one UserNamespace to another to be used for that user namespace?