Bug 1211965
| Summary: | [BLOCKED][SElinux][RHEL7.0] Sanlock's attempts to read metadata from vdsm's block storage get denied by selinux | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ori Gofen <ogofen> |
| Component: | vdsm | Assignee: | Ala Hino <ahino> |
| Status: | CLOSED CANTFIX | QA Contact: | Aharon Canan <acanan> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.5.1 | CC: | acanan, amureini, bazulay, ecohen, gklein, lpeer, lsurette, lvrabec, mgrepl, mmalik, plautrba, pvrabec, qe-baseos-security, rhodain, ssekidde, yeylon, ylavi |
| Target Milestone: | --- | Keywords: | Regression, TestOnly |
| Target Release: | 3.5.3 | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | storage | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1211697 | Environment: | |
| Last Closed: | 2015-04-22 06:53:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1211697 | ||
| Bug Blocks: | |||
|
Comment 1
Einav Cohen
2015-04-16 12:27:50 UTC
(In reply to Einav Cohen from comment #1) > changing Whiteboard from "SElinux-policy" to "infra" [not sure if this is an > 'infra' issue, but this is definitely not a 'ux' issue (the "ux" in > "SElin*ux*-policy" is marking this BZ as a 'ux' BZ in some reports)]. Setting to "storage", as seems like these selinuc policies effect the storage access. This is a RHEL7.0 SElinux bug, it is opened for QA monitoring purposes only as discussed at the storage team. A couple of notes: As Ori noted, the real issue is the underlying selinux-policy regression described in bug 1211697. This issue has already been fixed in RHEL 7.1, so RHEV 3.5.1 should be safe from it. Since we can't release an async 3.5.0-z to the RHEL 7.0 usecase, unless the underlying bug 1211697 is fixed really soon, there's nothing to do from RHEV's dev side. Once that is fixed, this bug will move to ON_QA, and left for RHEV's QA's discretion whether they want to verify it or just CLOSE CURRENTRELEASE×¥ Setting target to 3.5.3 in the meanwhile as I'm guessing that would be the timeline for the platform fix, but, as noted above, it doesn't really matter, as this is not coupled to any code/packaing change in RHEV. (In reply to Allon Mureinik from comment #4) > This issue has already been fixed in RHEL 7.1, so RHEV 3.5.1 should be safe > from it. References: The RHEL 7.1 bug is fixed in bug 1152538. The fix for RHEV 3.5.1 in bug 1177651 requires a higher version of sanlock that includes the fix for bug 1152538. 7.0.z is EOL and 3.5.1 hosts will require 7.1 anyway, so closing this one. Customers encountering this issue should upgrade to 7.1. Roman, can you make sure this is documented? Yaniv, please note that it is more likely that our costumers will encounter this bug during this upgrade procedure as the intermediate stage of mixed os cluster (7.0, 7.1) is quite risky. btw I would suggest that if and when upgrading a cluster of 7.0 hypervisors to 7.1, make sure that the first host that finishes the upgrade to 7.1 is selected as spm. (In reply to Ori Gofen from comment #8) > Yaniv, please note that it is more likely that our costumers will encounter > this bug during this upgrade procedure as the intermediate stage of mixed os > cluster (7.0, 7.1) is quite risky. > > btw I would suggest that if and when upgrading a cluster of 7.0 hypervisors > to 7.1, make sure that the first host that finishes the upgrade to 7.1 is > selected as spm. We do not have any other choice unless GSS pushes for a 7.0.z fix for this. Roman please be aware of this risk. |