Bug 951039 - KDE's restart and shutdown does not work while SELinux is enabled
Summary: KDE's restart and shutdown does not work while SELinux is enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F19Beta, F19BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-04-11 11:26 UTC by Martin Krizek
Modified: 2013-08-09 03:11 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-20 20:08:15 UTC
Type: Bug


Attachments (Terms of Use)

Description Martin Krizek 2013-04-11 11:26:41 UTC
Description of problem:
KDE's restart and shutdown does not work while SELinux is enabled. System hangs instead. Disabling SELinux "fixes" the issue. Tested in KVM with Fedora 19 Alpha RC2.

Version-Release number of selected component (if applicable):
kde-workspace-4.10.2-1.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Kickoff Application Launcher -> Leave -> {Restart|Shut down}
2.
3.
  
Actual results:
System hangs

Expected results:
System is restarted/shot down correctly.

Additional info:
Proposing as a Beta blocker per criterion:
"All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"

Comment 1 Rex Dieter 2013-04-11 12:28:29 UTC
I can reproduce, would appear I'm seeing denials wrt systemd poweroff.target alright.  Will post more details in a bit...

Comment 2 Rex Dieter 2013-04-11 12:56:08 UTC
triaging to selinux-policy-targetted.

here's a few snippets from /var/log/audit/audit.log wrt reboot and shutdown operations:

# grep reboot /var/log/audit/audit.log :

type=USER_AVC msg=audit(1365526555.562:470): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=-1 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=SERVICE_START msg=audit(1365526572.716:526): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="plymouth-reboot" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AVC msg=audit(1365684033.619:981): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=-1 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=SERVICE_START msg=audit(1365684052.560:1068): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="plymouth-reboot" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AVC msg=audit(1365684119.802:404): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=-1 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'


and, 
# grep reboot /var/log/audit/audit.log 
type=USER_AVC msg=audit(1365526555.562:470): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=-1 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=SERVICE_START msg=audit(1365526572.716:526): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="plymouth-reboot" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AVC msg=audit(1365684033.619:981): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=-1 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=SERVICE_START msg=audit(1365684052.560:1068): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="plymouth-reboot" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AVC msg=audit(1365684119.802:404): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=-1 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Comment 3 Daniel Walsh 2013-04-11 19:03:42 UTC
Why is this being differently from gdm?

Comment 4 Rex Dieter 2013-04-11 19:08:36 UTC
hard to say, I'm not privy to what gdm does exactly.

I do know that under certain circumstances, kdm calls /sbin/shutdown and /bin/reboot directly, and sometimes kde session manager marshalls that to systemd on dbus.  based on the denial, it's not clear to me which case is hit here.

Comment 5 Daniel Walsh 2013-04-11 19:12:33 UTC
I added the systemd guys to see what the proper way to do this is.  I have no problem adding the acces, which I believe is coming via dbus.

Comment 6 Kevin Kofler 2013-04-11 22:07:38 UTC
When KDM is running, KDE's ksmserver asks KDM to do the shutdown/reboot, which KDM does by invoking the shutdown binary or the halt and reboot binaries (depending on configuration) as root. KDM does not use the D-Bus interfaces.

GDM does not do shutdowns and reboots anymore, so the desktop has to request it from systemd (using D-Bus) instead. GNOME always uses this path, independently of the display manager being used.

There is a configuration UI in System Settings for who is allowed to shut down the computer using KDM, which is one of the reasons why the functionality still exists in KDM. If we switched KDE to always using systemd directly, the setting in the UI would get ignored and the PolicyKit setting would be used instead.

Comment 7 Michal Schmidt 2013-04-12 13:43:39 UTC
(In reply to comment #5)
> I added the systemd guys to see what the proper way to do this is.  I have
> no problem adding the acces, which I believe is coming via dbus.

If I'm reading this right, the access would be "allow xdm_t to start power_unit_file_t units". I have no problem with that either.

(In reply to comment #6)
> If we switched KDE to always using systemd directly, the setting in the UI
> would get ignored and the PolicyKit setting would be used instead.

IMHO deferring to PolicyKit for this kind of decisions is a good idea nevertheless.

Comment 8 Daniel Walsh 2013-04-12 18:03:22 UTC
Fixed in selinux-policy-3.12.1-30.fc19.noarch

Comment 9 Fedora Update System 2013-04-16 11:35:13 UTC
selinux-policy-3.12.1-31.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-31.fc19

Comment 10 Martin Krizek 2013-04-16 11:55:17 UTC
Confirming that selinux-policy-3.12.1-31.fc19 fixes the issue.

Comment 11 Fedora Update System 2013-04-16 16:14:49 UTC
Package selinux-policy-3.12.1-31.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-31.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5812/selinux-policy-3.12.1-31.fc19
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2013-04-20 20:08:18 UTC
selinux-policy-3.12.1-31.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 brian 2013-07-16 02:50:17 UTC
Using a fresh install of Fedora 19 x86_64, selinux-policy-3.12.1-63.fc19.noarch is failing to logout, shutdown, restart, etc.  No errors or log events I can find to provide more info.

Comment 14 Martin Krizek 2013-07-16 07:25:29 UTC
Using a clean install, fully updated F19 x86_64 (in kvm), I can't reproduce, everything works for me using the same version of selinux-policy as mentioned above.

Comment 15 jensberg 2013-07-16 12:11:42 UTC
Hi Brian,

(In reply to brian from comment #13)
> Using a fresh install of Fedora 19 x86_64,
> selinux-policy-3.12.1-63.fc19.noarch is failing to logout, shutdown,
> restart, etc.  No errors or log events I can find to provide more info.

I have had the same and fixed it by doinf an init 6 at console.

Comment 16 Fred 2013-07-16 22:02:48 UTC
The first thing I did when installing Fedora 19 KDE is to disable SELinux, and I have this problem too (Cannot logout/restart/shutdown KDE). So this is not a SELinux issue (or is not anymore).

I did some tests after deleting ~/.kde, and even my home directory, but I still have that problem.

I started to have this problem after the kernel update 3.9.9-302.fc19.x86_64. After other tests, I found out that it is somewhat related to nvidia proprietary driver (which was updated along with the kernel). If I use the nouveau driver, it solves the problem.

Comment 17 Kevin Kofler 2013-07-16 22:39:18 UTC
This bug report is most definitely about SELinux, it is even written in the subject line! Your bug is a completely different issue, and probably not even a Fedora bug (but a bug in the nvidia driver, which we do not ship). Please stop polluting this bug report with only vaguely related issues and report your nvidia driver bug directly to NVidia.

Comment 18 Clay 2013-07-17 06:07:45 UTC
In reply to Brian:

I can confirm the bug you are reporting, but this probably ought to be
entered as a new bug because it does not seem to be related to SELinux.

Using a fresh install of Fedora 19 with the following:
KDE desktop
systemd default.target = multi-user + grub2 GRUB_GFXMODE=text
nvidia driver loaded with akmod
yum update
reboot
setenforce 0

Click "Leave" button (kickoff launcher)

Expected result:
Log Out button appears
Clicking Log Out logs out of KDE (back to tty)

Actual result:
Log Out button appears
Log Out button does nothing when clicked

I also added the Leave button to the panel.

Click "Leave" button (panel)

Expected result:
Dialog pops up asking to Log Out or Lock

Actual result:
Leave button on panel does nothing when clicked

I tested this for 4 cases: root and normal user, and with setenforce 0 and 1.
Behavior is identical in all cases. 
No relevant messages being logged, including messages and audit.log.

Are you seeing this bug when using the nouveau driver?
If so, I think we could eliminate this relating to X.
This looks like a KDE issue to me.

Comment 19 Kevin Kofler 2013-07-17 23:02:52 UTC
What part of "Please stop polluting this bug report with only vaguely related issues" do you not understand??? And see comment 16 from Fred, which clearly states that "If I use the nouveau driver, it solves the problem." In other words, the problem you are seeing is with the nvidia proprietary driver and must be reported directly to NVidia. STOP FOLLOWING UP ON COMMENT #13, COMMENT #16 OR COMMENT #18 HERE!

Comment 20 Riku Seppala 2013-08-08 10:30:42 UTC
Fresh network install of Fedora 19 today august 8 2013 so I should have all the latest updates,right? Clicking log out does nothing.

Comment 21 brian 2013-08-09 03:11:05 UTC
This version of the bug is closed, as are several other incarnations of it.  The current open issue is bug #983110.  But you aren't alone...


Note You need to log in before you can comment on or make changes to this bug.