Bug 2017276

Summary: [4.10] Volume mounts not created with the correct security context
Product: OpenShift Container Platform Reporter: Christoffer Back <cback>
Component: StorageAssignee: Jan Safranek <jsafrane>
Storage sub component: Local Storage Operator QA Contact: Penghao Wang <pewang>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: unspecified CC: aos-bugs, ealcaniz, jsafrane, kkarampo, mavazque, wduan
Version: 4.8Keywords: FastFix
Target Milestone: ---   
Target Release: 4.10.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 2022720 2022740 2023306 (view as bug list) Environment:
Last Closed: 2022-03-10 16:22:07 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:
Bug Depends On:    
Bug Blocks: 2022740    

Description Christoffer Back 2021-10-26 08:19:44 UTC
Occasionally, some volume mount are not created with the correct security context. We have started two pods (of the same kind) in two different namespaces. Both pods ended up on the same worker. However, one of the pods did not start because one of the volume mounts (/data) had an incorrect security context:

*** Pod with an issue ***
$ oc project keep-vcu-operations-09
Now using project "keep-vcu-operations-09" on server "https://api.ocp065.exilis.npee.seki.gic.ericsson.se:6443".
[11:37][]$ oc rsh -c init eric-data-distributed-coordinator-ed-0
sh-4.4$ ls -lZ /data
ls: cannot open directory '/data': Permission denied
sh-4.4$ exit

*** After setting selinux mode to permissive on the worker ****
sh-4.4$ ls -lZd /data
drwxrwsrwx. 3 root 10000 system_u:object_r:unlabeled_t:s0 4096 Oct 25 03:58 /data

*** Working pod ***
[11:38][]$ oc project keep-vcu-operations-10
Now using project "keep-vcu-operations-10" on server "https://api.ocp065.exilis.npee.seki.gic.ericsson.se:6443".
[11:38][]$ oc rsh -c dced eric-data-distributed-coordinator-ed-0
sh-4.4$ ls -lZd /data
drwxrwsrwx. 6 root 10000 system_u:object_r:container_file_t:s0:c22,c28 4096 Oct 25 03:59 /data
sh-4.4$ exit

I've attached the pod descriptions for both the working and the non working pod.

When we deleted the non working pod, it moved to another worker, and it started without any issues.

I've attached the sosreport for the worker and a must-gather for the cluster.

Big files here so all attachments are in the related case - 03065228


Working pod - https://attachments.access.redhat.com/hydra/rest/cases/03065228/attachments/c54651e1-1ddd-4ed0-83ef-314d532f50f3?usePresignedUrl=true

Not working pod - https://attachments.access.redhat.com/hydra/rest/cases/03065228/attachments/26472f5d-ed57-4b03-908b-dd107dbd338f?usePresignedUrl=true

Must-gather - https://attachments.access.redhat.com/hydra/rest/cases/03065228/attachments/88865b0d-89f9-49e5-b6c0-dd144f1a7044?usePresignedUrl=true

sosreport - https://attachments.access.redhat.com/hydra/rest/cases/03065228/attachments/6602c32b-e367-43f6-bdd0-aea9a0a0d98a?usePresignedUrl=true

Comment 4 Jan Safranek 2021-10-27 10:00:42 UTC
Experimental PR: https://github.com/kubernetes/kubernetes/pull/105934
This needs some discussion upstream.

Comment 19 errata-xmlrpc 2022-03-10 16:22:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.