SELinux volume permission issues when playing kube file (rootless) #9371

ghost · 2021-02-15T13:29:50Z

/kind bug

Description

As mentioned in #8710 I have been having issues playing a kube file that I generated with podman. The problem seems to persist (I'm not 100% sure it's still the same issue).
Now on v3.0.0 I have permission issues with the volumes.

Steps to reproduce the issue:

SELinux is set to "enforcing".

Scenario A: running everything manually:

podman pod create pod -n testpod
create a simple Dockerfile that writes into a file on a mounted volume:

FROM docker.io/centos:centos8
USER root
CMD while true; do echo $(date) >> /testdir/testfile && sleep 3 ; done

build it then run the container in the pod: podman run -d --rm --name testcontainer --pod testpod -v $(pwd)/testdir:/testdir:Z testimage
let's look at the testfile:

 tail $(pwd)/testdir/testfile
Mon Feb 15 13:04:13 UTC 2021
Mon Feb 15 13:04:16 UTC 2021
Mon Feb 15 13:04:19 UTC 2021
Mon Feb 15 13:04:22 UTC 2021
Mon Feb 15 13:04:25 UTC 2021
Mon Feb 15 13:04:28 UTC 2021

So far so good.

Remove the testfile: rm -f $(pwd)/testdir/testfile

Scenario B: using podman generate:

podman pod create pod -n testpod
create a simple Dockerfile:

FROM docker.io/centos:centos8
USER root
CMD while true; do echo $(date) >> /testdir/testfile && sleep 3 ; done

build it then run the container in the pod: podman run -d --rm --name testcontainer --pod testpod -v $(pwd)/testdir:/testdir:Z testimage
generate a YAML file while the container is running: podman generate kube <pod id> > kube.yaml
the kube.yaml file looks like this:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2021-02-15T12:40:29Z"
  labels:
    app: testpod
  name: testpod
spec:
  containers:
  - command:
    - /bin/sh
    - -c
    - while true; do echo $(date) >> /testdir/testfile && sleep 3 ; done
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: container
      value: podman
    image: localhost/testimage:latest
    name: testcontainer
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        drop:
        - CAP_MKNOD
        - CAP_NET_RAW
        - CAP_AUDIT_WRITE
      privileged: false
      readOnlyRootFilesystem: false
      seLinuxOptions: {}
    volumeMounts:
    - mountPath: /testdir
      name: home-podman-testdir
    workingDir: /
  dnsConfig: {}
  restartPolicy: Never
  volumes:
  - hostPath:
      path: /home/podman/testdir
      type: Directory
    name: home-podman-testdir
status: {}

Play it: podman play kube kube.yaml
Check the testfile:

tail -f $(pwd)/testdir/testfile
tail: cannot open '/home/podman/testdir/testfile' for reading: No such file or directory

Let's see the logs:

podman logs testpod-testcontainer
/bin/sh: /testdir/testfile: Permission denied
/bin/sh: /testdir/testfile: Permission denied
/bin/sh: /testdir/testfile: Permission denied
/bin/sh: /testdir/testfile: Permission denied
/bin/sh: /testdir/testfile: Permission denied

Scenario B works when SELinux is set to pemissive mode.

Describe the results you received:
I would expect the container to write into the testfile in both Scenario A and B also with SELinux set to enforcing mode.

Describe the results you expected:

I get "permission denied" error message.

Additional information you deem important (e.g. issue happens only occasionally):
This issue happens since updating from 2.1.1 to 3.0.0. I had to skip 2.2.1 due to the issue mentioned above.

Output of podman version:

podman version
WARN[0000] Failed to add podman to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH
Version:      3.0.0
API Version:  3.0.0
Go Version:   go1.14.12
Built:        Sun Feb 14 18:48:35 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

podman info --debug
WARN[0000] Failed to add podman to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH
host:
  arch: amd64
  buildahVersion: 1.19.2
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.26-2.el8.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.26, commit: 8833a1127dabe0d76c18cc8f894ac48b62dfbda9'
  cpus: 4
  distribution:
    distribution: '"centos"'
    version: "8"
  eventLogger: journald
  hostname: ***********
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 795
      size: 1
    - container_id: 1
      host_id: 100000
      size: 10001
    uidmap:
    - container_id: 0
      host_id: 988
      size: 1
    - container_id: 1
      host_id: 100000
      size: 10001
  kernel: 4.18.0-240.10.1.el8_3.x86_64
  linkmode: dynamic
  memFree: 5099360256
  memTotal: 8346828800
  ociRuntime:
    name: crun
    package: crun-0.16-1.el8.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.16
      commit: eb0145e5ad4d8207e84a327248af76663d4e50dd
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /tmp/podman-run-988/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.8-3.el8.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 1931997184
  swapTotal: 2147479552
  uptime: 459h 44m 21.07s (Approximately 19.12 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/podman/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 2
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-1.el8.x86_64
      Version: |-
        fusermount3 version: 3.2.1
        fuse-overlayfs: version 1.4
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/podman/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 10
  runRoot: /tmp/podman-run-988/containers
  volumePath: /home/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1613324915
  BuiltTime: Sun Feb 14 18:48:35 2021
  GitCommit: ""
  GoVersion: go1.14.12
  OsArch: linux/amd64
  Version: 3.0.0

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

podman-3.0.0-2.el8.x86_64
container-selinux-2.145.0-1.el8.noarch

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

Yes

The text was updated successfully, but these errors were encountered:

rhatdan · 2021-02-15T14:00:52Z

This the YAML file include the :Z?

ghost · 2021-02-15T14:06:52Z

Yes, I created a pod, then a container in the pod with :Z :

podman run -d --rm --name testcontainer --pod testpod -v $(pwd)/testdir:/testdir:Z testimage

Then I generated the YAML from this pod.

rhatdan · 2021-02-15T14:24:17Z

Sorry I just saw the yaml file. If you add :Z to the image path, does it work?

    volumeMounts:
    - mountPath: /testdir:Z
      name: home-podman-testdir

ghost · 2021-02-15T14:28:39Z

No, it doesn't.
Here's the result:

podman exec -ti testpod-testcontainer bash
WARN[0000] Failed to add podman to systemd sandbox cgroup: exec: "dbus-launch": executable file not found in $PATH
[root@testpod /]# ls /
bin  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  testdir:Z  tmp  usr  var

rhatdan · 2021-02-15T18:54:59Z

Ok looks like two bugs in one... I will take a look, unless you want to take a stab?

ghost · 2021-02-16T09:53:40Z

@rhatdan , Thank you for asking but I'm not a programmer :( I am only a Podman user.

rhatdan · 2021-02-16T20:44:46Z

No problem, thanks for contributing the issue.

github-actions · 2021-03-19T00:17:40Z

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

lsunsi · 2021-03-29T17:10:23Z

I'm having the same issue described above. When I add the 'z' to the mountPath on the yaml, it just treats it as a part of the path.

tisc0 · 2021-04-13T19:59:17Z

#2536

github-actions · 2021-05-14T00:04:53Z

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

Allow users to specify options on the volume mount path. This will trigger relabels of user specifies :z,:Z Also will handle User Relabels if the user specifies :U Fixes: containers#9371 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>

Ian2020 · 2021-07-06T13:32:01Z

On 3.2.2 I'm still seeing this problem, :z is treated as part of the path as @lsunsi mentions above. My kube.yaml:

    volumeMounts:
    - mountPath: /var/www/html/storage:z
      name: my-data

If I run this up and look in the container it's created a dir storage:z:

> podman exec -it NAME ls /var/www/html/
...
drwxrwxr-x.  5 www-data www-data     98 Jul  6 13:23 storage
drwxr-xr-x.  1 root     root          0 Jul  3 12:10 storage:z
...

mheon · 2021-07-06T16:45:11Z

Can you open a fresh issue? The original issue was not supporting the :z flag at all, which is now fixed; it sounds like now we support it, but it's not working, which is a new bug.

tisc0 · 2021-07-06T21:58:58Z

Please @Ian2020 , could you do it ? Got no time to test this part for now, but will soon need this to be fixed too ! :)

Ian2020 · 2021-07-07T10:18:49Z

Before I create a new bug after some investigation I have found that the PR which closed this issue: #10339 never made it to the 3.2 branch, which is why the bug still persists for those of us not running from source.

The PR went into the master branch which no longer exists. Another commit was made the day before to main 4cc19f9 which looks like the same fix. So the fix is available, just not in the 3.2 branch.

Rather than being a totally new bug I think this one was just closed too early due to some confusion during the migration from master to main? If commit 4cc19f9 could now be released please I think we'll be able to see if the bug was really fixed. If you think this warrants a new issue though I am happy to create it.

openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 15, 2021

rhatdan self-assigned this Feb 15, 2021

github-actions bot added the stale-issue label Mar 19, 2021

rhatdan removed the stale-issue label Mar 22, 2021

tisc0 mentioned this issue Apr 13, 2021

make 'podman play kube' set local volume mounts #2536

Closed

EduardoVega mentioned this issue Apr 25, 2021

HostPath is currently the only supported VolumeSource #7626

Closed

github-actions bot added the stale-issue label May 14, 2021

rhatdan removed the stale-issue label May 14, 2021

rhatdan mentioned this issue May 14, 2021

Support automatic labeling of kube volumes #10339

Merged

openshift-merge-robot closed this as completed in #10339 May 17, 2021

Ian2020 mentioned this issue Jul 15, 2021

SELinux volume permission issues when playing kube file (rootless) #10938

Closed

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 bot locked as resolved and limited conversation to collaborators Sep 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SELinux volume permission issues when playing kube file (rootless) #9371

SELinux volume permission issues when playing kube file (rootless) #9371

ghost commented Feb 15, 2021 •

edited by ghost

Loading

rhatdan commented Feb 15, 2021

ghost commented Feb 15, 2021

rhatdan commented Feb 15, 2021

ghost commented Feb 15, 2021

rhatdan commented Feb 15, 2021

ghost commented Feb 16, 2021

rhatdan commented Feb 16, 2021

github-actions bot commented Mar 19, 2021

lsunsi commented Mar 29, 2021

tisc0 commented Apr 13, 2021

github-actions bot commented May 14, 2021

Ian2020 commented Jul 6, 2021

mheon commented Jul 6, 2021

tisc0 commented Jul 6, 2021

Ian2020 commented Jul 7, 2021

SELinux volume permission issues when playing kube file (rootless) #9371

SELinux volume permission issues when playing kube file (rootless) #9371

Comments

ghost commented Feb 15, 2021 • edited by ghost Loading

rhatdan commented Feb 15, 2021

ghost commented Feb 15, 2021

rhatdan commented Feb 15, 2021

ghost commented Feb 15, 2021

rhatdan commented Feb 15, 2021

ghost commented Feb 16, 2021

rhatdan commented Feb 16, 2021

github-actions bot commented Mar 19, 2021

lsunsi commented Mar 29, 2021

tisc0 commented Apr 13, 2021

github-actions bot commented May 14, 2021

Ian2020 commented Jul 6, 2021

mheon commented Jul 6, 2021

tisc0 commented Jul 6, 2021

Ian2020 commented Jul 7, 2021

ghost commented Feb 15, 2021 •

edited by ghost

Loading