I can reproduce, would appear I'm seeing denials wrt systemd poweroff.target alright.  Will post more details in a bit...

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=?'

Why is this being differently from gdm?

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.

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.

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.

(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.

Fixed in selinux-policy-3.12.1-30.fc19.noarch

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

Confirming that selinux-policy-3.12.1-31.fc19 fixes the issue.

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).

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.

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.

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.

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.

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.

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.

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.

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!

Fresh network install of Fedora 19 today august 8 2013 so I should have all the latest updates,right? Clicking log out does nothing.

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...