Bug 718377
Summary: | qemu + vnc + sasl needs a unique KRB5CACHEDIR to avoid selinux issues | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Anthony Messina <amessina> | ||||||
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | ||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | unspecified | CC: | berrange, clalance, crobinso, dpal, dwalsh, eblake, itamar, james.hogarth, jforbes, laine, martin, rbalakri, tim, veillard, virt-maint | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2016-12-02 13:27:35 UTC | Type: | --- | ||||||
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
Anthony Messina
2011-07-02 05:25:37 UTC
-rw-------. root root system_u:object_r:virt_tmp_t:s0 libvirt_0 -rw-------. qemu qemu system_u:object_r:svirt_tmp_t:s0:c911,c916 vnc_107 Is this a libvirt bug or an selinux-policy? Who creates this file? I think it is supposed to be used to prevent kerberos replay attacks? There's not enough information to understand what's going on here. Please provide the guest XML configuration and the /var/log/libvirt/qemu/$GUESTNAME.log logfile and your /etc/sasl2/qemu.conf file /etc/libvirt/qemu.conf: vnc_listen = "0.0.0.0" vnc_tls = 0 vnc_sasl = 1 /etc/sasl2/qemu.conf: mech_list: gssapi keytab: /etc/qemu/krb5.tab sasldb_path: /etc/qemu/passwd.db auxprop_plugin: sasldb f15-i686.log and f15-i686.xml attached. Created attachment 511574 [details]
qemu log
Created attachment 511575 [details]
qemu xml
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This continues to occur in Fedora 16: selinux-policy-targeted-3.10.0-56.fc16.noarch /var/tmp: -rw-------. root root system_u:object_r:virt_tmp_t:s0 libvirt_0 -rw-------. qemu qemu system_u:object_r:svirt_tmp_t:s0:c168,c523 vnc_107 This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Has someone fixed this by now? It also appears on CentOS 6.2 and therefore probably also on RHEL 6.2. It is related to #603642 where the discussion stopped in the middle. At the moment my options are either set SELinux to permissive or to remove the file manually after each connect. What does "This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work." mean, that seems to make my typical "trump SELinux with audit2allow" fail :-/ What do I need to do, Google does not turn up any good documentation. Basically SELinux is preventing access to this file because it was created by a different virtual machine. If you change the label to MCS Label s0, it will stop happening Is this the replay cache file? I think so. Any idea how to get this fixed properly? Currently cron is deleting the file every few minutes as a workaround... As per #603642 this is a replay cache - but given that all the VMs have the same access to the same keytab it doesn't really help at all.... The suggestion before the other bug for F13 was administratively closed was letting the qemu-kvm instances share the file - ie set a context that all VMs can reach... Doing a chcon system_u:object_r:svirt_tmp_t:s0 /var/tmp/vnc_XXX allows the user to view the consoles of all the VMs in virt-manager. Hmm, even though it sounds like sharing that file is okay, I think https://bugzilla.redhat.com/show_bug.cgi?id=603642#c10 about setting KRB5CACHEDIR to /var/lib/libvirt/qemu/$VMNAME is probably the easiest fix. danpb, does that sound good to you? Yeah, that seems like a reasonable approach This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reassigning to rawhide, as the string KRB5CACHEDIR is still not in libvirt.git. According to 'man kerberos', shouldn't the env-var be named KRB5RCACHEDIR (note the R at character 5)? Also, does the directory have to already exist, or will kerberos create it as needed? For that matter, is setting KRB5RCACHETYPE=none an appropriate alternative? Having answers to this question will make it easier to make sure the proposed patch is on the right track. Since this has lingered for a while, and there aren't many complains, moving to the upstream tracker. I no longer use libvirt and will be unable to test. Feel free to close. I no longer use libvirt and will be unable to test. Closing. |