Bug 1327154
| Summary: | Unable to access iscsi mount directory from pod when SElinux is enforcing | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Jianwei Hou <jhou> | ||||||
| Component: | Storage | Assignee: | Paul Morie <pmorie> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Jianwei Hou <jhou> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 3.2.0 | CC: | agoldste, aos-bugs, bchilds, eparis, jhou, jkrieger, tdawson | ||||||
| Target Milestone: | --- | Keywords: | Regression | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-09-27 09:38:00 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: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jianwei Hou
2016-04-14 11:16:01 UTC
First of all thank you for this excellent bug report. I was not able to reproduce this. ls -l /mnt/iscsi works for me. And the files listed above seem to have the correct labeling. Perhaps the SELinux issue is outside of openshift For example guide I followed to set up the iSCSI target (https://fedoraproject.org/wiki/Scsi-target-utils_Quickstart_Guide#Create_a_new_target_device) requires the backing file to have the target type label be tgtd_var_lib_t. Is that something that might be an issue for you ? In the future, any time that you find that setenforce 0 works around a problem, can you please include the output of `ausearch -ts recent` or all of /var/log/audit/audit.log as an attachment? Do you still have the those logs from this time period? Thank you for the suggestion. I've attached `ausearch -ts recent` and /var/log/audit/audit.log
Now I've found the way to reproduce it and why it happened.
1. Prepare iscsi target, create PV, PVC and setup iscsi initiator on the node
2. Create a first pod which has a value for pod.spec.securityContext.seLinuxOptions, eg:
```
"securityContext": {
"runAsUser": 101010,
"fsGroup": 123456,
"seLinuxOptions": {
"level": "s0:c13,c2"
}
},
```
3. Read/Write the mount dir from the pod, all operations are supported.
4. Delete the pod, then create a second pod using same PVC, make sure this pod does not have pod.spec.securityContext.seLinuxOptions, eg:
```
"securityContext": {
"runAsUser": 101010,
"fsGroup": 123456,
},
```
5. Read/Write the mount dir, this issue appears. Possibly because the previous pod has set selinux level but the second pod has not.
Created attachment 1150749 [details]
ausearch -ts recent
Created attachment 1150750 [details]
audit.log
As described in comment 3, I think this could also happen to rbd, aws, gce, cinder. Is this a valid user scenario? I see.. I don't think this is a bug we just have to get your settings correct. Can you follow the instructions here (starting at comment 5): https://bugzilla.redhat.com/show_bug.cgi?id=1326059#c5 Could you please post the result of `oc get <pod> -o yaml` (as opposed to the pod descriptor you submitted to the API server)? Is this still an issue? If so, could you please provide what Paul asked for in comment 9? Thanks! This is not an issue according to comment 7 and https://bugzilla.redhat.com/show_bug.cgi?id=1326059#c7. With selinuxContext type to MustRunAs in restricted scc, comment 3 is not reproducible. 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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1933 |