Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--volume with idmap copies with wrong owner/group #23467

Closed
M1cha opened this issue Aug 1, 2024 · 1 comment · Fixed by #23476
Closed

--volume with idmap copies with wrong owner/group #23467

M1cha opened this issue Aug 1, 2024 · 1 comment · Fixed by #23476
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@M1cha
Copy link
Contributor

M1cha commented Aug 1, 2024

Issue Description

If you use a volume which doesn't exist, podman will copy files from the underlying filesystem into the newly created volume. The documentation doesn't seem very clear about this but this is enabled by default.

The issue is, that when you also enable idmap on the volume, and your container runs with --userns=auto, then the copied files are owned by the temporary uid/gid.

Steps to reproduce the issue

Steps to reproduce the issue

  1. Make sure volume tmp does not exist
  2. podman run --rm -it --userns auto --volume tmp:/etc:idmap alpine:3.20 ls -lahn /etc/
  3. ls -lahn /var/lib/containers/storage/volumes/tmp/_data/

Describe the results you received

For Step 2, all files are owned by 65534:65534 (nobody/nogroup) within the container.
For Step 3, all files are owned by a dynamic ID outside the container.

Describe the results you expected

For Step 2, all files are owned by 0:0 (root/root) within the container.
For Step 3, all files are owned by 0:0 (root/root) outside the container.

podman info output

host:
  arch: arm64
  buildahVersion: 1.36.0
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.10-1.fc40.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: '
  cpuUtilization:
    idlePercent: 99.74
    systemPercent: 0.11
    userPercent: 0.15
  cpus: 8
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: coreos
    version: "40"
  eventLogger: journald
  freeLocks: 2038
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.11.0-0.rc1.20240729gitdc1c8034e31b.16.fc41.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 13312339968
  memTotal: 16716324864
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.11.0-1.fc40.aarch64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.11.0
    package: netavark-1.11.0-1.fc40.aarch64
    path: /usr/libexec/podman/netavark
    version: netavark 1.11.0
  ociRuntime:
    name: crun
    package: crun-1.15-1.fc40.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.15
      commit: e6eacaf4034e84185fd8780ac9262bbf57082278
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20240624.g1ee2eca-1.fc40.aarch64
    version: |
      pasta 0^20240624.g1ee2eca-1.fc40.aarch64-pasta
      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/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: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-2.fc40.aarch64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.5
  swapFree: 0
  swapTotal: 0
  uptime: 7h 47m 12.00s (Approximately 0.29 days)
  variant: v8
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 4
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.imagestore: /usr/lib/containers/storage
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 491511971840
  graphRootUsed: 373449494528
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 5
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.1.1
  Built: 1717459200
  BuiltTime: Tue Jun  4 00:00:00 2024
  GitCommit: ""
  GoVersion: go1.22.3
  Os: linux
  OsArch: linux/arm64
  Version: 5.1.1

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

As you can see in podman info, you can see that I'm running stable fedora coreOS with a newer kernel (6.11-rc1). I did that because I use very recent rk3588 hw, but the issue was also present on the kernel which is shipped with that version of fedora).

Additional information

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

@M1cha M1cha added the kind/bug Categorizes issue or PR as related to a bug. label Aug 1, 2024
@giuseppe
Copy link
Member

giuseppe commented Aug 1, 2024

opened a PR:

@stale-locking-app stale-locking-app bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Nov 1, 2024
@stale-locking-app stale-locking-app bot locked as resolved and limited conversation to collaborators Nov 1, 2024
giuseppe added a commit to giuseppe/libpod that referenced this issue Nov 18, 2024
if idmap is specified for a volume, reverse the mappings when copying
up from the container, so that the original permissions are maintained.

Closes: containers#23467

Signed-off-by: Giuseppe Scrivano <[email protected]>
(cherry picked from commit 3ae1568)
giuseppe added a commit to giuseppe/libpod that referenced this issue Nov 18, 2024
if idmap is specified for a volume, reverse the mappings when copying
up from the container, so that the original permissions are maintained.

Closes: containers#23467

Signed-off-by: Giuseppe Scrivano <[email protected]>
(cherry picked from commit 3ae1568)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants