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

Container created with --pid host returns operation not permitted on copy in F34 #9985

Closed
JayDoubleu opened this issue Apr 9, 2021 · 7 comments · Fixed by #10327
Closed
Assignees
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

@JayDoubleu
Copy link

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

/kind bug

Description

Container created with --pid host returns operation not permitted error when trying to copy file into container.

Steps to reproduce the issue:

  1. Create container with podman run --ipc host --name pidtest --pid host --privileged --security-opt label=disable --ulimit host --user root:root -it registry.fedoraproject.org/fedora:34 /bin/bash

  2. Try copying file into container touch /tmp/test && podman cp /tmp/test pidtest:/tmp/test

Describe the results you received:
Error: "/tmp/test" could not be found on container pidtest: operation not permitted

Describe the results you expected:
File should be copied and no errors returned.

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

Output of podman version:

podman version
Version:      3.1.0
API Version:  3.1.0
Go Version:   go1.16
Built:        Tue Mar 30 14:29:36 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

podman info --debug
host:
  arch: amd64
  buildahVersion: 1.20.0
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.27-1.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 24
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: thinkD
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.11.11-300.fc34.x86_64
  linkmode: dynamic
  memFree: 26587058176
  memTotal: 33655853056
  ociRuntime:
    name: crun
    package: crun-0.18-5.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.18
      commit: 808420efe3dc2b44d6db9f1a3fac8361dde42a95
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/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
    selinuxEnabled: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc34.x86_64
    version: |-
      slirp4netns version 1.1.8+dev
      commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 8589930496
  swapTotal: 8589930496
  uptime: 20h 36m 23.57s (Approximately 0.83 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/jaydoubleu/.config/containers/storage.conf
  containerStore:
    number: 10
    paused: 0
    running: 1
    stopped: 9
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.5.0-1.fc34.x86_64
      Version: |-
        fusermount3 version: 3.10.2
        fuse-overlayfs: version 1.5
        FUSE library version 3.10.2
        using FUSE kernel interface version 7.31
  graphRoot: /var/home/jaydoubleu/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 5
  runRoot: /run/user/1000/containers
  volumePath: /var/home/jaydoubleu/.local/share/containers/storage/volumes
version:
  APIVersion: 3.1.0
  Built: 1617110976
  BuiltTime: Tue Mar 30 14:29:36 2021
  GitCommit: ""
  GoVersion: go1.16
  OsArch: linux/amd64
  Version: 3.1.0

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

podman-3.1.0-1.fc34.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

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

Fedora 34 Silverblue

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Apr 9, 2021
@mheon
Copy link
Member

mheon commented Apr 9, 2021

@vrothberg PTAL

@JayDoubleu JayDoubleu changed the title Container created with --pid host returns operation not permitted on F34 Container created with --pid host returns operation not permitted on copy in F34 Apr 9, 2021
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented May 13, 2021

$ podman run -d --name pidtest --pid=host -it registry.fedoraproject.org/fedora sleep 500
c97639c3f123c82926c0f1adb9b39f1afa721649ba3f66fe671114d01c1a5448
$ podman cp pidtest:/etc/resolv.conf /tmp/
Error: "/etc/resolv.conf" could not be found on container pidtest: operation not permitted
$ podman run -d --name pidtest1 -it registry.fedoraproject.org/fedora sleep 500
5949bb2d09ea9387feef663b982e6671c70f6122ef111f8dfb743ba62fa28875
$ podman cp pidtest1:/etc/resolv.conf /tmp/

@nalind @vrothberg does the copier rely on the pid namespace?

@rhatdan rhatdan self-assigned this May 13, 2021
@rhatdan
Copy link
Member

rhatdan commented May 13, 2021

I found it.

rhatdan added a commit to rhatdan/podman that referenced this issue May 13, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 13, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 13, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 14, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 14, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 17, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 18, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue May 19, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@JayDoubleu
Copy link
Author

@rhatdan what are the odds of this patch landing in F34 any time soon?

@rhatdan
Copy link
Member

rhatdan commented May 21, 2021

It should be in podman 3.2 RC3 which is scheduled to be released next week. Correct @mheon

@mheon
Copy link
Member

mheon commented May 21, 2021 via email

mheon pushed a commit to mheon/libpod that referenced this issue May 25, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Procyhon pushed a commit to Procyhon/podman that referenced this issue May 27, 2021
When attempting to copy files into and out of running containers
within the host pidnamespace, the code was attempting to join the
host pidns again, and getting an error. This was causing the podman
cp command to fail. Since we are already in the host pid namespace,
we should not be attempting to join.  This PR adds a check to see if
the container is in NOT host pid namespace, and only then attempts to
join.

Fixes: containers#9985

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
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.

4 participants