Bug 1973184

Summary: [kata] Regular user have no write access right to mounted pv when using kata container runtime
Product: OpenShift Container Platform Reporter: Wei Duan <wduan>
Component: sandboxed-containersAssignee: Ariel Adam <aadam>
Status: CLOSED DUPLICATE QA Contact: Cameron Meadors <cmeadors>
Severity: low Docs Contact:
Priority: low    
Version: 4.8CC: aos-bugs, dinechin, dwalsh, jfreiman, jsafrane
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-21 08:35:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Wei Duan 2021-06-17 11:39:59 UTC 
Description of problem:
Regular user(not kubeadmin) have no write access right to mounted pv when using kata container runtime.

Version-Release number of selected component (if applicable):
4.8.0-0.nightly-2021-06-16-020345

How reproducible:
Always

Steps to Reproduce:
1. Install the kata-operator and make it as container engine
2. Login into cluster as regular user 
$ oc whoami
testuser-10

3. Create pod and pvc, could not write data to mounted volume 
sh-4.4$ ls -ldZ /mnt/local/
drwxrwsr-x 3 root 1000670000 ? 4096 Jun 17 11:29 /mnt/local/

sh-4.4$ touch /mnt/local/a           
touch: cannot touch '/mnt/local/a': Permission denied

sh-4.4$ id
uid=1000670000(1000670000) gid=0(root) groups=0(root),1000670000

sh-4.4$ mount | grep mnt
kataShared on /mnt/local type virtiofs (rw,relatime)

4. Check on the node:
sh-4.4# mount | grep pvc-bbb65e4c-07e0-4b2c-872b-f21843288038
/dev/sdc on /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/wduan-0617g-gcp-rxnl9--pvc-bbb65e4c-07e0-4b2c-872b-f21843288038 type ext4 (rw,relatime,seclabel)
/dev/sdc on /var/lib/kubelet/pods/705292c8-6915-4612-aca4-83b7ba7e6ad0/volumes/kubernetes.io~gce-pd/pvc-bbb65e4c-07e0-4b2c-872b-f21843288038 type ext4 (rw,relatime,seclabel)

sh-4.4# ls -lZd /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/wduan-0617g-gcp-rxnl9--pvc-bbb65e4c-07e0-4b2c-872b-f21843288038
drwxrwsr-x. 3 root 1000670000 system_u:object_r:container_file_t:s0:c10,c26 4096 Jun 17 11:29 /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/wduan-0617g-gcp-rxnl9--pvc-bbb65e4c-07e0-4b2c-872b-f21843288038

Actual results:
Regular user have no write access right to mounted volume.

Expected results:
Regular user should have the write access right to mounted volume.
Comment 7 Christophe de Dinechin 2021-07-05 17:05:47 UTC 
@dwalsh Could you tell me what you think should happen based on the content of the SELinux labels?
Comment 8 Daniel Walsh 2021-07-07 11:35:01 UTC 
How is the volume mounted into the kata-container?  virtiofsd?
Comment 9 Christophe de Dinechin 2021-07-07 15:30:50 UTC 
Could we have the precise configuration to know how the volume was mounted?
Comment 10 Wei Duan 2021-07-08 00:48:44 UTC 
Hi Christophe, 

1. Looking into the pod:
sh-4.4$ mount | grep mnt
kataShared on /mnt/local type virtiofs (rw,relatime)

2. Check on the node:
sh-4.4# mount | grep pvc-bbb65e4c-07e0-4b2c-872b-f21843288038
/dev/sdc on /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/wduan-0617g-gcp-rxnl9--pvc-bbb65e4c-07e0-4b2c-872b-f21843288038 type ext4 (rw,relatime,seclabel)
/dev/sdc on /var/lib/kubelet/pods/705292c8-6915-4612-aca4-83b7ba7e6ad0/volumes/kubernetes.io~gce-pd/pvc-bbb65e4c-07e0-4b2c-872b-f21843288038 type ext4 (rw,relatime,seclabel)

Here is my test yaml file (image could be updated if the image could not be pulled from your side):
---
kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    name: frontendhttp
spec:
  containers:
    - name: myfrontend
      image: quay.io/openshifttest/storage@sha256:a05b96d373be86f46e76817487027a7f5b8b5f87c0ac18a246b018df11529b40 
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
      - mountPath: "/mnt/local"
        name: local
  volumes:
    - name: local
      persistentVolumeClaim:
        claimName: mypvc

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
Comment 12 Jens Freimann 2022-09-21 08:35:52 UTC 

*** This bug has been marked as a duplicate of bug 1904609 ***