| Summary: | Build (OZ) failed with Permission denied when SELinux is enabled | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Martin Kočí <mkoci> |
| Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | brad, crobinso, dallan, jlaska, whayutin, xen-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 791210 | Environment: | |
| Last Closed: | 2012-02-28 16:12:40 UTC | Type: | --- |
| 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: | 791210 | ||
| Bug Blocks: | |||
|
Description
Martin Kočí
2012-02-23 10:15:43 UTC
Based on the discussion in BZ 791210 it appears that the process that's spawning libvirtd is doing so with the wrong context, so I don't think that there's anything that libvirt can do to help. Jiri, am I right about that? Just a small update.. If libvirtd is restarted from HUDSON/JENKINS, then you reproduce the issue and you get this context: unconfined_u:system_r:unconfined_java_t:s0-s0:c0.c1023 root 30469 1 0 Feb23 ? 00:00:00 libvirtd --daemon Then if you restart libvirtd from command line you get this context (which works) unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 root 10905 1 6 07:26 ? 00:00:00 libvirtd --daemon Yeah, we can't do much when we are started with a wrong context. It's up to the parent to execute libvirtd with the right context either explicitly or by using service {re,}start libvirtd which would do the right thing. But only if selinux-policy allows the parent to do so, of course.
Jiri, given what you've said, I think it's pretty clear there is nothing libvirt can do about this situation and this is not a libvirt bug, but what does Martin need to do to resolve his problem? I.e, what component should this be changed to? I don't know to be honest. From comment 2, it seems it's HUDSON/JENKINS messing up with libvirtd. So this would need to be fixed there. To be more precise: There is os.system(service libvirtd restart) line in the python script which is triggered from HUDSON/JENKINS. This causes change of the context to unconfined_u:system_r:unconfined_java_t I see, I'm not sure how exactly service changes the contexts but I guess it can only do so if executed within a context that allows it do so. That is, it's likely service command run in unconfined_u:system_r:unconfined_java_t context is not allowed to set the right context when calling init scripts. Which is a good thing. So one possible way to fix this issue would be to stop messing with services. (Why do you need to restart libvirtd anyway?) Otherwise you can try talking to selinux-policy guys to check if my understanding is correct and if anything can be done to allow your use case. Ok, thanks; I'm going to close as not a bug. Martin, if you'd like further input from the project, please mail the upstream list (libvir-list) I'm OK with that. |