12:01 p.m.
After I booted my FC11 test system and did an update, I tried to
shutdown and got this failure.
I clicked system->shutdown->shutdown_button and the system hung. An
investigation of the log shows that attached behavior.
If I log out and click the shutdown button it works, so it seems to only
happen when using the button while logged in.
Running 'shutdown -h' as root also works.
I assume that this is an SElinux behavior, before I BZ it, is it intentional?
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Apr 29 09:39:13 fc11s1 ntpd[1350]: kernel time sync status change 0001
Apr 29 09:43:42 fc11s1 ntpd[1350]: synchronized to 69.10.36.4, stratum 2
Apr 29 09:43:48 fc11s1 yum: Updated: libgcc-4.4.0-3.i586
Apr 29 09:43:49 fc11s1 yum: Updated: kernel-headers-2.6.29.1-111.fc11.i586
Apr 29 09:43:50 fc11s1 yum: Updated: kernel-firmware-2.6.29.1-111.fc11.noarch
Apr 29 09:43:51 fc11s1 init: Re-executing /sbin/init
Apr 29 09:43:51 fc11s1 yum: Updated: glibc-2.9.90-22.i686
Apr 29 09:43:52 fc11s1 yum: Updated: libstdc++-4.4.0-3.i586
Apr 29 09:43:52 fc11s1 yum: Updated: 1:cups-libs-1.4-0.b2.15.fc11.i586
Apr 29 09:43:52 fc11s1 yum: Updated: libgomp-4.4.0-3.i586
Apr 29 09:43:52 fc11s1 yum: Updated: nash-6.0.83-1.fc11.i586
Apr 29 09:43:52 fc11s1 yum: Updated: grubby-6.0.83-1.fc11.i586
Apr 29 09:43:52 fc11s1 yum: Updated: 32:bind-libs-9.6.1-0.2.b1.fc11.i586
Apr 29 09:43:58 fc11s1 dbus: Reloaded configuration
Apr 29 09:44:05 fc11s1 yum: Updated: 1:gdm-2.26.1-4.fc11.i586
Apr 29 09:44:15 fc11s1 yum: Updated: glibc-common-2.9.90-22.i586
Apr 29 09:44:15 fc11s1 yum: Updated: mkinitrd-6.0.83-1.fc11.i586
Apr 29 09:44:16 fc11s1 yum: Updated: glibc-headers-2.9.90-22.i586
Apr 29 09:44:37 fc11s1 yum: Installed: kernel-2.6.29.1-111.fc11.i586
Apr 29 09:44:37 fc11s1 yum: Updated: cpp-4.4.0-3.i586
Apr 29 09:44:38 fc11s1 yum: Updated: gupnp-0.12.7-1.fc11.i586
Apr 29 09:44:38 fc11s1 yum: Updated: xorg-x11-drv-ati-6.12.2-7.fc11.i586
Apr 29 09:44:38 fc11s1 yum: Updated: 1:gdm-user-switch-applet-2.26.1-4.fc11.i586
Apr 29 09:44:38 fc11s1 yum: Updated: 32:bind-utils-9.6.1-0.2.b1.fc11.i586
Apr 29 09:44:38 fc11s1 yum: Updated: libbdevid-python-6.0.83-1.fc11.i586
Apr 29 09:44:38 fc11s1 dbus: Reloaded configuration
Apr 29 09:44:41 fc11s1 yum: Updated: 1:cups-1.4-0.b2.15.fc11.i586
Apr 29 09:44:41 fc11s1 yum: Updated: xorg-x11-drv-mga-1.4.10-1.fc11.i586
Apr 29 09:44:41 fc11s1 yum: Updated: upstart-0.3.9-24.fc11.i586
Apr 29 09:44:41 fc11s1 yum: Updated: nscd-2.9.90-22.i586
Apr 29 09:44:42 fc11s1 yum: Updated: glibc-devel-2.9.90-22.i586
Apr 29 09:44:42 fc11s1 yum: Updated: memtest86+-2.11-9.fc11.i586
Apr 29 09:44:43 fc11s1 yum: Updated: gcc-4.4.0-3.i586
Apr 29 09:46:39 fc11s1 init: tty4 main process (1443) killed by TERM signal
Apr 29 09:46:39 fc11s1 init: tty5 main process (1444) killed by TERM signal
Apr 29 09:46:39 fc11s1 init: tty2 main process (1454) killed by TERM signal
Apr 29 09:46:39 fc11s1 init: tty3 main process (1467) killed by TERM signal
Apr 29 09:46:39 fc11s1 init: tty6 main process (1468) killed by TERM signal
Apr 29 09:46:39 fc11s1 init: rc0 main process (5306) killed by TERM signal
Apr 29 09:46:39 fc11s1 gnome-session[1652]: WARNING: Unable to stop system: Not privileged
for action: org.freedesktop.consolekit.system.stop no
Apr 29 09:46:39 fc11s1 gnome-session[1652]: WARNING: Unable to stop system: Not privileged
for action: org.freedesktop.consolekit.system.stop no
Apr 29 09:46:39 fc11s1 gnome-session[1652]: WARNING: Unable to stop system: Not privileged
for action: org.freedesktop.consolekit.system.stop no
Apr 29 09:46:39 fc11s1 gnome-session[1652]: WARNING: Unable to stop system: Not privileged
for action: org.freedesktop.consolekit.system.stop no
Apr 29 09:46:39 fc11s1 gnome-session[1652]: WARNING: Unable to stop system: Not privileged
for action: org.freedesktop.consolekit.system.stop no
12:24 p.m.
On Wed, Apr 29, 2009 at 01:01:57PM -0400, Bill Davidsen wrote:
After I booted my FC11 test system and did an update, I tried to
shutdown and got this failure.
I clicked system->shutdown->shutdown_button and the system hung. An
investigation of the log shows that attached behavior.
If I log out and click the shutdown button it works, so it seems to only
happen when using the button while logged in.
Running 'shutdown -h' as root also works.
I assume that this is an SElinux behavior, before I BZ it, is it intentional?
Is there nothing in audit.log related to this?
--
"Any fool can know. The point is to understand" --Albert Einstein
Bored??
http://fiction.wikia.com/wiki/Fuqwit1.0
http://fiction.wikia.com/wiki/Coding_the_Magic_into_the_Eight_Ball
7:19 p.m.
max wrote:
On Wed, Apr 29, 2009 at 01:01:57PM -0400, Bill Davidsen wrote:
> After I booted my FC11 test system and did an update, I tried to
> shutdown and got this failure.
> I clicked system->shutdown->shutdown_button and the system hung. An
> investigation of the log shows that attached behavior.
>
> If I log out and click the shutdown button it works, so it seems to only
> happen when using the button while logged in.
>
> Running 'shutdown -h' as root also works.
>
> I assume that this is an SElinux behavior, before I BZ it, is it intentional?
>
Is there nothing in audit.log related to this?
The only thing which might be useful is attached. Time fits, and nothing within
minutes of that.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
type=AVC msg=audit(1241012798.972:26): avc: denied { create } for pid=5301
comm="shutdown" scontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023
tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=netlink_audit_socket
type=SYSCALL msg=audit(1241012798.972:26): arch=40000003 syscall=102 success=no exit=-13
a0=1 a1=bf8159c0 a2=2faff4 a3=3 items=0 ppid=5299 pid=5301 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="shutdown" exe="/sbin/shutdown"
subj=system_u:system_r:consolekit_t:s0-s0:c0.c1023 key=(null)
type=CRED_DISP msg=audit(1241012799.095:27): user pid=2069 uid=0 auid=501 ses=1
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred
acct="root" exe="/bin/su" (hostname=?, addr=?, terminal=pts/3
res=success)'
type=USER_END msg=audit(1241012799.097:28): user pid=2069 uid=0 auid=501 ses=1
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close
acct="root" exe="/bin/su" (hostname=?, addr=?, terminal=pts/3
res=success)'
type=SYSTEM_RUNLEVEL msg=audit(1241012799.232:29): user pid=5331 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='old-level=5 new-level=0:
exe="/sbin/runlevel" (hostname=?, addr=?, terminal=console res=success)'
type=AVC msg=audit(1241012799.315:30): avc: denied { create } for pid=5336
comm="shutdown" scontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023
tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=netlink_audit_socket
type=SYSCALL msg=audit(1241012799.315:30): arch=40000003 syscall=102 success=no exit=-13
a0=1 a1=bf9fb880 a2=2faff4 a3=3 items=0 ppid=5313 pid=5336 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="shutdown" exe="/sbin/shutdown"
subj=system_u:system_r:consolekit_t:s0-s0:c0.c1023 key=(null)
11:40 p.m.
On Wed, 2009-04-29 at 13:01 -0400, Bill Davidsen wrote:
After I booted my FC11 test system and did an update, I tried to
shutdown and got this failure.
I clicked system->shutdown->shutdown_button and the system hung. An
investigation of the log shows that attached behavior.
If I log out and click the shutdown button it works, so it seems to only
happen when using the button while logged in.
Running 'shutdown -h' as root also works.
I assume that this is an SElinux behavior, before I BZ it, is it intentional?
If the system *is* intentionally configured (whether by default or by
customization) to disallow mortal users to shutdown or reboot the
system, it should not "hang", but produce a friendly error message
informing the user they are not allowed to do that. If it does not do
that, it seems like a usability bug which should be reported.
I see that Bug 495326 was closed; after updating and relabeling, are you
still experiencing this problem and getting AVC denials? If so, I would
open a new bug if there isn't another one already.
It does not sound like a rational default configuration if you are not
allowed to reboot the system as a normal user, but to get around that
restriction, you simply need to log out. IMO, that would be a separate
problem which should also be reported if that's the behavior you are
seeing with the default configuration.
-B.
5470
days inactive
5477
days old
3 comments
3 participants
participants (3)
-
Bill Davidsen -
Christopher Beland -
max