Bug 696051

Summary: unable to suspend, restart, or shutdown graphically with selinux-policy*-3.9.16-14.fc16.noarch
Product: [Fedora] Fedora Reporter: Andre Robatino <robatino>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dwalsh, mgrepl, redwolfe, stephent98
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-15 10:55:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andre Robatino 2011-04-13 07:02:38 UTC
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

Comment 1 Andre Robatino 2011-04-13 07:10:05 UTC
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.

Comment 2 Miroslav Grepl 2011-04-13 09:57:50 UTC
Fixed in selinux-policy-3.9.16-15.fc15 and selinux-policy-3.9.16-15.fc16

Thanks for testing.

Comment 3 Steve Tyler 2011-04-13 14:26:01 UTC
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.

Comment 4 Andre Robatino 2011-04-13 14:45:44 UTC
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).

Comment 5 Steve Tyler 2011-04-13 17:09:50 UTC
(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.

Comment 6 G.Wolfe Woodbury 2011-04-13 19:36:37 UTC
Confirmed in VBox 4.0.4 guests

Comment 7 Steve Tyler 2011-04-13 19:46:21 UTC
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.

Comment 8 Andre Robatino 2011-04-15 10:55:43 UTC
selinux-policy*-3.9.16-15.fc16 finally made it to rawhide and the problem is fixed there, so closing.