Hide Forgot
Description of problem: With selinux-policy*-3.9.16-14.fc16.noarch, any attempt to shutdown or restart graphically fails. Attempting to do so while logged in only results in logging out, attempting any of suspend, restart, shutdown from the login screen fails. Each failed attempt corresponds to an entry like the following in /var/log/messages: Apr 13 02:49:29 localhost setroubleshoot: SELinux is preventing /bin/bash from execute access on the file /bin/systemctl. For complete SELinux messages. run sealert -l 4d2461aa-991c-44fe-bc3a-2a92968533f3 and the corresponding sealert output is SELinux is preventing /bin/bash from execute access on the file /bin/systemctl. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that bash should be allowed execute access on the systemctl file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep ck-system-stop /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp On F15, I had the same problem and downgrading to selinux-policy*-3.9.16-13.fc16.noarch fixed it. Unfortunately, on rawhide the earlier version is not available. Version-Release number of selected component (if applicable): selinux-policy-3.9.16-14.fc16.noarch selinux-policy-targeted-3.9.16-14.fc16.noarch How reproducible: always
Sorry, should have said "On F15, I had the same problem and downgrading to selinux-policy*-3.9.16-13.fc15.noarch fixed it". Using "halt" or "reboot" from a VT works fine as a workaround.
Fixed in selinux-policy-3.9.16-15.fc15 and selinux-policy-3.9.16-15.fc16 Thanks for testing.
Confirming that restart and shutdown from the gdm menu have no effect. Suspending from the gdm menu works for me. Did you get an sealert? ConsoleKit-0.4.4-1.fc15.x86_64 gdm-3.0.0-1.fc15.x86_64 selinux-policy-3.9.16-14.fc15.noarch selinux-policy-targeted-3.9.16-14.fc15.noarch I believe that these are the restart and shutdown bugs: Bug 695789 - SELinux is preventing /bin/bash from 'execute' accesses on the file /bin/systemctl. Bug 695818 - SELinux is preventing /bin/bash from 'execute' accesses on the file /bin/systemctl.
I don't normally use suspend, so am not too familiar with it, and also am testing in a VM (VirtualBox 4.04). Don't know if that matters. In any case, I checked (in rawhide), and I do NOT get an sealert when trying to suspend from the gdm menu, but suspend isn't working, either (I can still switch back and forth between VTs 1 and 2 to check for the sealert).
(In reply to comment #4) > I don't normally use suspend, so am not too familiar with it, and also am > testing in a VM (VirtualBox 4.04). Don't know if that matters. In any case, I > checked (in rawhide), and I do NOT get an sealert when trying to suspend from > the gdm menu, but suspend isn't working, either (I can still switch back and > forth between VTs 1 and 2 to check for the sealert). During F14 testing, I found that suspend in a VM (qemu-kvm) did not work, but never reported that, IIRC. Will try F15 in a VM and report back. I have had suspend bugs at various times (<F15) on bare-metal installs that were not selinux related.
Confirmed in VBox 4.0.4 guests
Likewise confirmed with qemu-kvm that restart and shutdown fail and the sealerts are the same as in Bug 695789 and Bug 695818. Further, suspend fails, but there is no corresponding sealert. Suspend works as expected on two bare-metal installs, so I believe the suspend failure in a VM is due to a bug in the VM and not an selinux issue. Andre, if you are seeing a suspend failure with a bare-metal install, you probably have a xorg or kernel bug. Poking around in the logs might give a clue. CC me if you open any bugs.
selinux-policy*-3.9.16-15.fc16 finally made it to rawhide and the problem is fixed there, so closing.