Bug 230155
Summary: | Sleep fails with permission denied | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Karl MacMillan <kmacmill> |
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | davidz, dwalsh, florin, richard |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-04-01 16:48:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 150226 |
Description
Karl MacMillan
2007-02-26 21:52:08 UTC
Are you logging in via gdm? If no, please close as dupe of bug 228110. Yes, I'm logged in via gdm. Please try this in permissive mode. I was just going through the same thing with dwalsh... Thanks. Permissive doesn't help. I have been working on this today and now have $XDG_SESSION_COOKIE showing up, with an updated policy. But still getting error on sleep. Feb 27 11:54:41 redsox gnome-power-manager: (dwalsh) Suspending computer because the lid has been closed, and the ac adapter removed (and gconf is okay) Feb 27 11:54:41 redsox gnome-power-manager: (dwalsh) Permission denied: Not in active session code='30' quark='g-exec-error-quark' Feb 27 11:54:41 redsox gnome-power-manager: (dwalsh) Resuming computer Feb 27 11:54:41 redsox gnome-power-manager: (dwalsh) suspend failed No avc messages Mmm.. can you run hald with # hald --daemon=no --verbose=yes There's a ton of debug output. Then kill g-p-m and start g-p-m again. I'm interested in the output after you make g-p-m call Suspend() on HAL. What happens is this 1. g-p-m connects to the system bus 2. when it calls into HAL we get the pid/uid from D-Bus 3. given the pid, HAL asks ConsoleKit, via GetSessionFromUnixProcess() (see http://fedoraproject.org/wiki/Desktop/FastUserSwitching for details) about the desktop session 4. HAL caches the pid/uid/session and tracks whether that session is active 5. when g-p-m calls Suspend() we look up the cached information Because of the caching going on, I need g-p-m to be restarted. Thanks. *** Bug 230240 has been marked as a duplicate of this bug. *** I've got the same problem on a T43; here's the hald output you requested. 13:37:23.834 [W] hald_dbus.c:1078: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0: Unable to lookup session information for process '4138' 13:37:23.834 [I] hald_dbus.c:4073: Caller :1.32 (uid 500, pid 4138) for interface org.freedesktop.Hal.Device.CPUFreq on add-on method SetCPUFreqGovernor for /org/freedesktop/Hal/devices/computer is not in any session; refusing service 13:37:23.834 [W] hald_dbus.c:96: Permission denied: Not in active session 13:37:23.835 [I] hald_dbus.c:4073: Caller :1.32 (uid 500, pid 4138) for interface org.freedesktop.Hal.Device.CPUFreq on add-on method GetCPUFreqGovernor for /org/freedesktop/Hal/devices/computer is not in any session; refusing service 13:37:23.836 [W] hald_dbus.c:96: Permission denied: Not in active session 13:37:23.837 [I] hald_dbus.c:4073: Caller :1.32 (uid 500, pid 4138) for interface org.freedesktop.Hal.Device.CPUFreq on add-on method GetCPUFreqGovernor for /org/freedesktop/Hal/devices/computer is not in any session; refusing service 13:37:23.837 [W] hald_dbus.c:96: Permission denied: Not in active session 13:37:23.838 [I] hald_dbus.c:4073: Caller :1.32 (uid 500, pid 4138) for interface org.freedesktop.Hal.Device.CPUFreq on add-on method SetCPUFreqPerformance for /org/freedesktop/Hal/devices/computer is not in any session; refusing service 13:37:23.838 [W] hald_dbus.c:96: Permission denied: Not in active session 13:37:24.050 [I] hald_dbus.c:4151: OK for method 'SetPowerSave' with signature 'b' on interface 'org.freedesktop.Hal.Device.SystemPowerManagement' for UDI '/org/freedesktop/Hal/devices/computer' and execpath 'hal-system-power-set-power-save' 13:37:24.050 [I] hald_dbus.c:3310: Caller :1.32 (uid 500, pid 4138) for interface org.freedesktop.Hal.Device.SystemPowerManagement on exec'ed method SetPowerSave for /org/freedesktop/Hal/devices/computer is not in any session; refusing service 13:37:24.050 [W] hald_dbus.c:96: Permission denied: Not in active session 13:37:24.377 [W] hald_dbus.c:96: No property battery.remaining_time on device with id /org/freedesktop/Hal/devices/acpi_BAT0 13:37:24.383 [W] hald_dbus.c:96: No property info.vendor on device with id /org/freedesktop/Hal/devices/acpi_BAT0 13:37:24.397 [W] hald_dbus.c:96: No property info.is_recalled on device with id /org/freedesktop/Hal/devices/acpi_BAT0 Probably the problem is that you need to allow ConsoleKit to look in /proc/<pic>/environ for the pid that HAL is passing. That's what XDG_SESSION_COOKIE is just for... Ah, I think I confused part of the problem. My /proc/$(pidof gnome-power-manager)/environ did not contain XDG_SESSION_COOKIE, until I turned SELinux to Permissive and logged back in. Then suspend worked OK. With SELinux set to enforcing, I get the following message in audit.log *at login* (not at sleep time): type=USER_AVC msg=audit(1172603954.457:157): user pid=1846 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: denied { send_msg } for msgtype= method_call interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters dest=org.freedesktop.ConsoleKit spid=2492 tpid=2068 scontext=system_u:system_ r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' So that's probably the SELinux problem that dwalsh has apparently solved above. It didn't show up in dmesg or setroubleshoot so I assumed this was a different problem. Sorry for any confusion. David, whats the status of this ? It's a SELinux bug (which I think is fixed as it works for me on fresh installs), so reassigning.. ... and also closing! (since it's working for me on a fresh T3 install). Feel free to reopen if this still doesn't work. |