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

OCI runtime permission denied when trying to use --userns container:id #7547

Closed
j0057 opened this issue Sep 5, 2020 · 4 comments · Fixed by #7578
Closed

OCI runtime permission denied when trying to use --userns container:id #7547

j0057 opened this issue Sep 5, 2020 · 4 comments · Fixed by #7578
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

@j0057
Copy link

j0057 commented Sep 5, 2020

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

/kind bug

Description

I'm trying to run a container as a sidecar to another container, by sharing the user and net namespaces using the --user container:id and --net container:id options. This gives an "OCI runtime permission denied" error.

Steps to reproduce the issue:

  1. Start the main container: sudo podman run --rm -it --name test --uidmap 0:60000:1000 --gidmap 0:60000:1000 --net sys alpine:3.12

  2. Try to start the sidecar container: sudo podman run --rm -it --name test-sidecar --userns container:test --net container:test alpine:3.12

Describe the results you received:

An error message: Error: container_linux.go:370: starting container process caused: process_linux.go:459: container init caused: rootfs_linux.go:47: preparing rootfs caused: permission denied: OCI runtime permission denied error

Describe the results you expected:

Both the test and test-sidecar containers should run successfully and be visible from the host system as running under uid 60000.

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

Repro step 2 works if I remove the --userns flag, but then the main process runs as root not user 60000; it gives exactly the same error message if I run it with --uidmap 0:60000:1000 instead.

Output of podman version:

Version:      2.0.6
API Version:  1
Go Version:   go1.15
Git Commit:   27362ba1ad8879ea71610fa68a651a1651e0180f
Built:        Tue Sep  1 21:43:39 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.1
  cgroupVersion: v1
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.20, commit: 13244db638cf987c415298a3c23393ae5abeb885'
  cpus: 8
  distribution:
    distribution: arch
    version: unknown
  eventLogger: file
  hostname: muon
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.8.5-arch1-1
  linkmode: dynamic
  memFree: 18484121600
  memTotal: 33629425664
  ociRuntime:
    name: runc
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc92
      commit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
      spec: 1.0.2-dev
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 34357637120
  swapTotal: 34357637120
  uptime: 18h 36m 46.5s (Approximately 0.75 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 13
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 1
  Built: 1598989419
  BuiltTime: Tue Sep  1 21:43:39 2020
  GitCommit: 27362ba1ad8879ea71610fa68a651a1651e0180f
  GoVersion: go1.15
  OsArch: linux/amd64
  Version: 2.0.6

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

$ pacman -Q podman
podman 2.0.6-1

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.):

@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Sep 5, 2020
@j0057
Copy link
Author

j0057 commented Sep 5, 2020

The --net sys in repro step 1 refers to the following CNI config file (although the error reproduces exactly the same with the default podman network):

{
   "cniVersion": "0.4.0",
   "name": "sys",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br-sys",
         "isGateway": true,
         "ipMasq": true,
         "ipam": {
            "type": "host-local",
            "routes": [
               {
                  "dst": "0.0.0.0/0"
               }
            ],
            "ranges": [
               [
                  {
                     "subnet": "172.28.19.0/24",
                     "gateway": "172.28.19.1"
                  }
               ]
            ]
         }
      },
      {
         "type": "portmap",
         "capabilities": {
            "portMappings": true
         }
      },
      {
         "type": "firewall",
         "backend": ""
      }
   ]
}

@j0057 j0057 changed the title OCI runtime permission denied when trying to use --usens container:id OCI runtime permission denied when trying to use --userns container:id Sep 5, 2020
@giuseppe
Copy link
Member

giuseppe commented Sep 6, 2020

could you try using crun instead of runc as the OCI runtime?

@j0057
Copy link
Author

j0057 commented Sep 7, 2020

I did, adding --runtime crun to both podman commands, and still got an error in step 2: Error: make `/var/lib/containers/storage/overlay/cb46d77853d327613e84f76653cf7912827980bec6fc8fe103201fac326a8215/merged` private: Permission denied: OCI runtime permission denied error.

giuseppe added a commit to giuseppe/libpod that referenced this issue Sep 9, 2020
when joining an existing container user namespace, read the existing
mappings so the storage can be created with the correct ownership.

Closes: containers#7547

Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
@giuseppe
Copy link
Member

giuseppe commented Sep 9, 2020

PR here: #7578

giuseppe added a commit to giuseppe/libpod that referenced this issue Sep 9, 2020
when joining an existing container user namespace, read the existing
mappings so the storage can be created with the correct ownership.

Closes: containers#7547

Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
giuseppe added a commit to giuseppe/libpod that referenced this issue Sep 10, 2020
when joining an existing container user namespace, read the existing
mappings so the storage can be created with the correct ownership.

Closes: containers#7547

Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
giuseppe added a commit to giuseppe/libpod that referenced this issue Sep 10, 2020
when joining an existing container user namespace, read the existing
mappings so the storage can be created with the correct ownership.

Closes: containers#7547

Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
giuseppe added a commit to giuseppe/libpod that referenced this issue Sep 10, 2020
when joining an existing container user namespace, read the existing
mappings so the storage can be created with the correct ownership.

Closes: containers#7547

Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
edsantiago pushed a commit to edsantiago/libpod that referenced this issue Sep 14, 2020
when joining an existing container user namespace, read the existing
mappings so the storage can be created with the correct ownership.

Closes: containers#7547

Signed-off-by: Giuseppe Scrivano <giuseppe@scrivano.org>
@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 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 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.

3 participants