Description of problem: Create a pod that mounts a hostpath, access the files from the pod, 'Permission denied' is seen. Set selinux to permissive, hostpath mount dir is r/w accessible. Version-Release number of selected component (if applicable): openshift v3.0.1.0-338-g9dfce43 kubernetes v1.0.0 How reproducible: Always Steps to Reproduce: Edit scc to enable host dir volume plugin 1. Create PV, PVC and pod: oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/hostpath/local.yaml oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/hostpath/claim.yaml oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/hostpath/pod.yaml 2. Access the files of the mount dir from the pod oc exec localpd -it -- bash [root@localpd /]# ls /mnt ls: cannot open directory /mnt: Permission denied 3. Set selinux to permissive, repeat step 3 On node: setenforce 0 Actual results: After step 2: oc exec localpd -it -- bash [root@localpd /]# ls /mnt ls: cannot open directory /mnt: Permission denied After step 3: problem is gone [root@localpd /]# ls /mnt index.html Expected results: Should be r/w accessible with selinux enforced Additional info: Also see https://bugzilla.redhat.com/show_bug.cgi?id=1222060
This isn't going to work with SELinux enforcing because you're trying to mount a path under /tmp. Files under /tmp get tmp_t which isn't accessible from svirt_sandbox_file_t (which is what the container runs as). For this to work, you'll need to use a path that has a context usable from svirt_sandbox_file_t.
Thanks! I've changed /tmp to /root in my example, and I started the container with docker directly: docker run -v /root/data01/:/mnt:Z -it docker.io/jhou/hello-openshift /bin/bash Then I've managed to r/w the mounted dir, it has svirt_sandbox_file_t context. [root@minion1 ~]# docker exec -it 65245be3265b bash [root@65245be3265b /]# ls bin dev etc hello-openshift home lib lib64 lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var [root@65245be3265b /]# cd /mnt/ [root@65245be3265b mnt]# ls [root@65245be3265b mnt]# touch file [root@65245be3265b mnt]# ls file [root@65245be3265b mnt]# rm file rm: remove regular empty file 'file'? y [root@65245be3265b mnt]# cd .. [root@65245be3265b /]# ls -Zd mnt/ drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c327,c835 mnt/ So now I think the problem is with kubernetes which does not change the hostpath's selinux security context when the container is created.
Hou Jianwei- What makes you think that? Do you still get 'permission denied' ?
We need more info about what failure you're seeing now.
Hi, Paul Morie, sorry I did not make it clear. Yes, I still get 'permission denied', the following is the default SElinux contexts of the mount dir using hostpath(the pv/pvc/pod info is in the description): # oc exec localpd -it bash bash-4.2$ ls /mnt/ ls: cannot open directory /mnt/: Permission denied bash-4.2$ ls /mnt/ -Zd drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /mnt/ From the node, I changed the SElinux context: chcon -u system_u -r object_r -t svirt_sandbox_file_t -l s0 /data01/ Then from the container, I'm able to run 'ls' without getting 'permission denied' bash-4.2$ ls /mnt/ bash-4.2$ echo $? 0 bash-4.2$ ls -Zd /mnt/ drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0 /mnt/ I take it as a bug because I think kubernetes should help me set correct SELinux contexts so that whenever I have a pod created with a hostpath volume(or other types), I'm able to access the volume from the pod without seeing any 'permission denied' error.
We can read/write in mounted hostdir when selinux is enforcing with following version, # openshift version openshift v3.1.0.4-16-g112fcc4 kubernetes v1.1.0-origin-1107-g4c8e6f4 etcd 2.1.2 Once the bug is ON_QA, we can move it to verified.
tested and verified on: openshift v3.1.1.6 kubernetes v1.1.0-origin-1107-g4c8e6f4 etcd 2.1.2