Bug 189078

Summary: G-P-M upgrade blocks remote system suspension/hibernation
Product: [Fedora] Fedora Reporter: Emerson House <ehbase-linux>
Component: gnome-power-managerAssignee: John (J5) Palmieri <johnp>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 5CC: jkeck, 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: 2006-04-15 22:36:10 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:

Description Emerson House 2006-04-15 17:48:37 UTC 
Description of problem:

G-P-M updates result in power manager utilites (pm-hibernate, pm-suspend, etc.)
no longer working from remote console.

Version-Release number of selected component (if applicable):

2.14.1-1

How reproducible:

Always

Steps to Reproduce:
1.Boot a Fedora machine with g-p-m installed and enabled.
2.log into this machine with a remote console - for example ssh.
3.run pm-hibernate, or run sudo pm-hibernate, or login as root and run pm-hibernate.
  
Actual results:

Command line returns to prompt with no warnings or messages, but no action is taken.

Expected results:

Hibernation or suspension of target machine.


Additional info:

Yes I know this is intended and seems to carried out by the pam module stack. 
There is proably someting about it buried in a changelog somewhere.  I suspect
that other people may also run into this as there are legitmate reasons to
remotely suspend a system just as there are legitimate reasons to block remote
suspension of a system.  I would consider the the bug fixed if there was just a
slight amount of assistance in pointing out the correct areas in the systems
guides to research the pam module stack and how to enable/disable the behavior.
   It isn't real obvious from the PAM documentation exactly what controls this
behavior.  I am willing to fix it myself, but it would be nice not to have to
become a full PAM expert and read all of the documentation.  I think other
people might also appreciate a little bit of guidance.
Comment 1 Richard Hughes 2006-04-15 18:50:43 UTC 
This isn't a g-p-m bug.

I think you need to edit /etc/dbus-1/system.d/hal.conf and relax the permissions
checks a bit, something like changing policy context for default from deny to allow.

I'm not sure why this doesn't allow you to do this as root tho.

Richard.
Comment 2 Emerson House 2006-04-15 22:36:10 UTC 
G-P-M upgrade installs links in /usr/bin that involk consolehelper which causes
the behavior described.  Directly calling /usr/bin/pm-hibernate gets arround the
problem.

Consolehelper is apparently doing what it is designed to do although the MAN
page doesn't really explain things and refers you to the html documentation
installed in the /usr/share/doc/pam/html directory.  Obviously it is a good
thing to be able to prevent system suspend or hibernate from remote consoles,
but it may also be desireable at times.  Directly calling /usr/bin/pm-hibernate
will work but it is a hack (in the older sense that it is undocumented and
unsuportable).  Consolehelper is obviously trying to establish some systematic
administration of the behavior, but to be honest the documentation isn't very
clear and it is hard to tell if execution of programs from remote consoles is
blocked on a per user or per program basis.
Comment 3 Emerson House 2006-04-15 22:39:48 UTC 
OOPs, that could be confusing.  The actual programs are in /usr/sbin, so calling
/usr/sbin/pm-hibernate is the suggested fix.  (or even more of a hack deleting
the links in /usr/bin.)