Red Hat Bugzilla – Full Text Bug Listing
|Summary:||setsebool -P allow_daemons_use_tty=1|
|Product:||[Fedora] Fedora||Reporter:||Michael Quinlan <mquinlan>|
|Component:||qemu||Assignee:||Justin M. Forbes <jforbes>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||11||CC:||amit.shah, berrange, dwmw2, ehabkost, gcosta, gemi, itamar, jaswinder, jforbes, knoel, markmc, paul, scottt.tw, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-06-28 10:56:12 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Michael Quinlan 2009-10-06 19:05:42 EDT
Description of problem: Direct text from setroubleshooter about qemu: SELinux prevented qemu from using the terminal 5. In most cases daemons do not need to interact with the terminal, usually these avc messages can be ignored. All of the confined daemons should have dontaudit rules around using the terminal. Please file a bug report against this selinux-policy. If you would like to allow all daemons to interact with the terminal, you can turn on the allow_daemons_use_tty boolean. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. install qemu on FC11; virt-manager; create several FC11 VMs using local FC11 DVD iso 2. SELinux starts getting many security violations -- qemu fails to create VM # setroubleshooter shows over half a dozen security violations 3. setsebool -P allow_daemons_use_tty=1; does NOT solve the problem(s). # The system continues to deny access to terminal 4, 5, etc. with each # new VM 4. vi /etc/mstab and added workaround: devpts /dev/pts devpts rw,gid=5,mode=620 0 0 # This helps but mtab gets reset/written on every boot??? back to default: devpts /dev/pts devpts rw 0 0 Actual results: qemu does not have the necessary permission to create new VMs. Actual setroubleshooter text: ========== Summary: SELinux is preventing qemu (svirt_t) "setrlimit" svirt_t. Detailed Description: SELinux denied access requested by qemu. It is not expected that this access is required by qemu and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. =========== and =========== Summary: SELinux is preventing pt_chown (ptchown_t) "read write" to /var/lib/libvirt/images/Archangel.img (svirt_image_t). Detailed Description: SELinux denied access requested by pt_chown. /var/lib/libvirt/images/Archangel.img may be a mislabeled. /var/lib/libvirt/images/Archangel.img default SELinux type is virt_image_t, but its current type is svirt_image_t. Changing this file back to the default type, may fix your problem. =============================== Expected results: qemu to have all the necessary selinux policies and privileges to create VMs. Sun's Virtual box works fine with no security violations. Click-click VMs. Additional info: VERY easy to reproduce on a new machine. I just installed FC11, updated everything to the latest version 10/06/2009; Everything is current, installed qemu; virt-manager; etc. and cannot create VMs with creating a long list of security policies and workarounds. Now it is booting, but I still have not successfully created an FC11 VM on FC11 using qemu. I have done many, many VMs using Sun's virtualbox with no problem. I would prefer qemu. I think.... I definely would like to see working FC11 VM in QEMU, but it is still installing after running all night long. Sun Virtualbox installs in less than an hour to create a new FC11 VM.
Comment 1 Michael Quinlan 2009-10-06 19:37:49 EDT
I am fairly new to Fedora/bugzilla, I should have been more clear on my closing comments. I have not been able to successfully create a new VM using QEMU. My newly create VMs have maxed out CPU loads and... Right now. I have two new qemu VMs "stuck"??? at Fedora's install message: "Creating filesystem on /dev/sda1" The qemu Details->Performance pages show Disk I/O is disabled???? Is the disk disabled? or just the performance monitoring of the disks? At any rate, I have never progressed beyond this stage with qemu.
Comment 2 Michael Quinlan 2009-10-07 18:09:01 EDT
I came in this morning and the new VM was still at "Creating filesystem on /dev/sda1" after running all night FC11 VM on FC11. I updated to the latest qemu updates that were waiting for me this morning (thank you :-) ): qemu-system-x86-0.10.6-6.fc11 and I am still receiving the same selinux error: ============= Detailed Description SELinux prevented qemu from using the terminal 1. In most cases daemons do not need to interact with the terminal, usually these avc messages can be ignored. All of the confined daemons should have dontaudit rules around using the terminal. Please file a bug report against this selinux-policy. If you would like to allow all daemons to interact with the terminal, you can turn on the allow_daemons_use_tty boolean. Allowing Access Changing the "allow_daemons_use_tty" boolean to true will allow this access: "setsebool -P allow_daemons_use_tty=1." ========== Hopefull, I will be able to get my first qemu FC11 VM running on FC11 now, although with at least a few setroubleshooting errors noted here. Note that this is a 32-bit version, NOT 64 bit. 32 bit FC11 VM on a 32 bit FC11 host with 512 bytes of RAM, I know, I am looking for more RAM, an error message would be nice, if it is just never going to work... I have restarted my machine after the updates and I am trying again. If all goes well, I should know in "about an hour"...
Comment 3 Michael Quinlan 2009-10-07 18:44:58 EDT
It works great (except for the setroubleshooter policy errors, I set my domain name, timezone, etc. Everything works great right up until "Creating filesystem on /dev/sda1" that is where it is now, (same place it was "stuck" all night. I notice that it is not formatting, just creating the file system.... hopefully I will see in a few more minutes that it continues on. --- always testing the boundary conditions... makes for superior coding... --- sorry about the 512 MB, but I am very poor and trying to decide if I should put new money into old DDR2 RAM. If this works, I will.
Comment 4 Michael Quinlan 2009-10-07 18:57:22 EDT
No Joy. Still stuck at: "Creating filesystem on /dev/sda1" System "feels" responsive, no apparent thrashing, I am writing this update on the same machine, so it does not seem to be memory limit related. Good luck for my memory, someone in the office may have some RAM for me. Cannot create FC11 VM on FC11 host i386 version, with latest qemu updates as of 10/07/2009. Stuck on: "Creating filesystem on /dev/sda1" --- even after leaving overnight on several occasions. It is stuck now, I will update if the status changes.
Comment 5 Michael Quinlan 2009-10-07 19:02:24 EDT
Created attachment 364048 [details] Screenshot: The FC11 VM install "stuck" at Creating filesystem The FC11 VM install "stuck" at Creating filesystem
Comment 6 Michael Quinlan 2009-10-07 19:04:31 EDT
Created attachment 364049 [details] Sreenshot: Disk I/O in Performance is disabled Is the Disk I/O in qemu disabled or just the performance monitoring of the VM? Cannot see any disk activity that may be helpful in understanding the failure to install FC11 VM. ISO passes verify during VM install.
Comment 7 Michael Quinlan 2009-10-07 19:13:00 EDT
Comment on attachment 364049 [details] Sreenshot: Disk I/O in Performance is disabled Oh! You can't take a screenshot in qemu of the Performance page, it ALWAYS takes a screenshot of the console, not the details page you are looking at. I didn't know that.
Comment 8 Michael Quinlan 2009-10-08 20:59:38 EDT
I left the machine overnight to create the 32 bit FC11 VM in QEMU. It is still stuck on "Creating filesystem on /dev/sda1" I will leave it from now and over the weekend, 5 days to see if it has progressed at all. I hypothesize that it will not. It would be GREAT if QEMU VM window had a little disk light in the windows status at the bottom of the window, that blinks when the hard disk is being accessed like Sun's Virtualbox does, that way I could see if it is actively writing to the disk (blinking on and blinking off), or just hung (solid on, or solid off) as I suspect. I will try to install Sun's VirtualBox on this machine and see if it works or has the same problem next week.
Comment 9 Michael Quinlan 2009-10-13 00:04:23 EDT
OK, new test results are just in. Installed VirtualBox-OSE on FC11 with 512 MB RAM DDR2 Set RAM to 125 MB FC11 VM installed on FC11 and booted fine. works fine in VirtualBox ======================================== Next Test: Set QEMU VM RAM to 125 MB and attempt to install FC11 VM in QEMU.
Comment 10 Michael Quinlan 2009-10-13 18:00:00 EDT
OK, the verdict is in. VirtualBox-OSE is up and running FC11 VM with 125 MB RAM QEMU is VERY SLOW, so slow I thought it hung. QEMU has many selinux errors, including: Summary SELinux is preventing pt_chown (ptchown_t) "read write" to /var/lib/libvirt/images/QI-Admin.img (svirt_image_t). Detailed Description SELinux denied access requested by pt_chown. /var/lib/libvirt/images/QI-Admin.img may be a mislabeled. /var/lib/libvirt/images/QI-Admin.img default SELinux type is virt_image_t, but its current type is svirt_image_t. Changing this file back to the default type, may fix your problem. File contexts can be assigned to a file in the following ways. Files created in a directory receive the file context of the parent directory by default. The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhclient_t type and creates a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. If you believe this is a bug, please file a bug report against this package. QEMU is VERY SLOW to create FC11 VM with 125 MB RAM Off I go, creating VirtualBox VMs with FC11, I have to use VirtualBox-OSE instead of QEMU, because QEMU is SO SLOW or fails every time. Various hangs: - FC11 VM 490 MB QEMU hangs "Creating filesystem on /dev/sda1" - FC11 VM 125 MB QEMU VERY SLOW in anaconda, works fine in VirtualBox-OSE 512 MB FC11 i386 version Dom0. Still testing QEMU. I will let you know if the FC11 VM ever finishes with 125 MB in the VM and starts working, like it does in VirtualBox-OSE. I can live with a slow, but working install, if it succeeds.
Comment 11 Michael Quinlan 2009-10-13 18:02:14 EDT
Created attachment 364664 [details] QEMU FC11 VM appears hung with FC11 125 MB VM This works in VirtualBox-OSE. Appears hung in QEMU. A small (blinking) disk icon in the status bar on the VM windows would make it easier to see if disk activity is taking place (like in VirtualBox-OSE). Otherwise, I think the QEMU VM is hung when it is not.
Comment 12 Michael Quinlan 2009-10-13 20:13:40 EDT
OK. That pretty much wraps up the testing.... VirtualBox with Dom0=512MB,FC11 VM=125MB,FC11 Works fine. QEMU with Dom0=512MB,FC11 VM=125MB,FC11 Hangs at anacondra entering text mode install -- see sreenshot. It is vital to test the boundary conditions: I will have to use VirtualBox for now... Good luck to QEMU.
Comment 13 Michael Quinlan 2009-10-13 20:15:25 EDT
Created attachment 364668 [details] FC11 install QEMU hang QEMU hangs installing FC11 VM=125MB RAM. Works fine in VirtualBox ... no errors. QEMU also get various selinux errors see above, VirtualBox gets none and works fine.
Comment 14 Paul Howarth 2010-04-21 10:11:40 EDT
Bug appears to have been assigned to wrong component: reassigning from qcad to qemu.
Comment 15 Bug Zapper 2010-04-28 06:43:28 EDT
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Comment 16 Bug Zapper 2010-06-28 10:56:12 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.