Do not show suspend/hiberate related UI if suspend is disabled in polkit

Bug #432598 reported by TH on 2009-09-18
284
This bug affects 52 people
Affects Status Importance Assigned to Milestone
DeviceKit-Power
Fix Released
Medium
OEM Priority Project
Undecided
Unassigned
Session Menu
Fix Released
Medium
Ted Gould
gnome-power-manager (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned
Lucid
Undecided
Unassigned
gnome-session (Ubuntu)
Low
Unassigned
Karmic
Undecided
Unassigned
Lucid
Low
Unassigned
indicator-session (Ubuntu)
Low
Indicator Applet Developers
Karmic
Undecided
Unassigned
Lucid
Low
Indicator Applet Developers
upower (Ubuntu)
Medium
Martin Pitt
Karmic
Medium
Unassigned
Lucid
Medium
Martin Pitt

Bug Description

Binary package hint: gnome-power-manager

System: Ubuntu Karmic alpha6
gnome-power-manager: 2.27.92.0ubuntu1

The following settings in gconf-editor aren't respected:
/apps/gnome-power-manager/general/can_hibernate
/apps/gnome-power-manager/general/can_suspend

The problem can be reproduced at least in these three dialogs:

Power Management Preferences:
Even though suspend or hibernate is disabled, the option is still visible as an action.

Shut Down the Computer:
When I press the shutdown-button on my laptop to enter "interactive-mode", both actions are visible, regardless of the gconf-settings.

Indicator-applet-session:
Both suspend and hiberante shows up, regardless of the gconf-settings.
(Although this could be a bug in the applet itself. See bug 423608)

Other gconf-settings seems to work alright, even if I've changed them to non-default values.

Related branches

lp:~indicator-applet-developers/indicator-session/ubuntu
Ken VanDine: Pending requested 2011-10-13
lp:~pitti/indicator-session/libupower-glib
Martin Pitt (community): Resubmit on 2010-02-16
Ted Gould: Needs Information on 2010-02-16
David Barth: Needs Information on 2010-02-16
Changed in gnome-power-manager (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
unggnu (unggnu) wrote :

Confirmed in Karmic and gnome-power-manager also ignores the not existing swap partition.

Daniel Holbert (dholbert) wrote :

FWIW: This worked in Jaunty, so this is a new bug in Karmic.

This is particularly important for people running with encrypted swap partitions, because hibernate doesn't play nicely with encrypted swap yet. Whenever I shutdown / suspend / restart, I'm constantly afraid that I'll accidentally cliick the button for "hibernate" instead, and have who-knows-what happen :(

unggnu (unggnu) wrote :

@Daniel
Just for the records, there is a workaround to use hibernate even with encrypted swap.
It is relatively easy possible with the decrypt_derived script.
It is described here: http://crunchbanglinux.org/forums/topic/4299/howto-install-with-encrypted-swap-and-data-partitions/

Geert Jan Alsem (gj-alsem) wrote :

Note though, that when I press the special "Sleep" button that is on my keyboard, Ubuntu does respect "can_suspend", and gives me a notification telling me sleep is disabled.

But, like stated above, the Shut Down dialog does not respect the setting. Kind of a big deal for me because Suspend messes up my PC a bit.

brianx (brianechard) wrote :

I am having this same problem. Is there anyway to increase the priority of this bug? It may seem small to some but I would even donate money to fix this because its important to me.

StephanBeal (sgbeal) wrote :

i've got just the opposite problem - i can't get hibernate/suspend options to show up in Gnome (they do in KDE). They worked fine in 9.04, but disappeared in 9.10. The various gconf-editor hacks i've read about have made no difference.

brianx (brianechard) wrote :

Are there any creative solutions to this problem until the official fix is developed and released? This goes directly to StephanBeal's comment. Even though it's not respecting the settings in gconf-editor it has to be getting the value somewhere. Can we remove the button in a different location in gonf-editor.

This is not only Suspend/Hibernate issue. Also when you want in gconf-editor disable user switching, you will have still option to switch user in logout dialog window. It's simply totaly broken in Karmic :(

brianx (brianechard) wrote :

I did a search of issues regarding issues affecting genome power-management and this lists 5th when sorted by issues affecting the most users. Everyone make sure at the top of this bug it says "This bug affects me too".

Same problem in openSUSE 11.2 with GNOME :(

stacktracer (stacktracer) wrote :

Workaround from http://ubuntuforums.org/showthread.php?t=1305081 -- in /usr/share/polkit-1/actions/org.freedesktop.devicekit.power.policy, find the

  <allow_active>yes</allow_active>

lines, and change the "yes" to "no". Save the file and reboot. (Yes, you do have to edit the file -- the pre-Karmic "Authorizations" gui is gone.)

Suspend and hibernate still appear in the logout menu, but all they do is lock the screen.

On Fri, Nov 20, 2009 at 6:16 PM, stacktracer <email address hidden> wrote:

> Suspend and hibernate still appear in the logout menu, but all they do
> is lock the screen.
>
>
On my system this file doesn't exist. Maybe that's why my Suspend/Hibernate
options do not appear any more (since upgrading to Karmic). Would you mind
posting the contents of your file?

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

@stacktracer's workaround worked for me.

@StephanBeal: That file exists on my Ubuntu Karmic system -- I'm not sure why it doesn't on yours. "dpkg -S [filename]" says that it's owned by the package "devicekit-power". Anyway, I'm attaching my copy, for your benefit. (with the workaround already applied for the "hibernate" section)

@Daniel:
stephan@jareth:~$ dpkg -S org.freedesktop.devicekit.power.policy
dpkg: *org.freedesktop.devicekit.power.policy* not found.

Possibly because this machine has been through too many dist-updates, and
it's now confused. Hibernation worked in previous versions, though, and i
miss it sorely.

stephan@jareth:~$ apt-cache search devicekit
...
devicekit-power - abstraction for power management
...
stephan@jareth:~$ sudo apt-get install devicekit-power
...

stephan@jareth:~$ dpkg -S org.freedesktop.devicekit.power.policy
devicekit-power:
/usr/share/polkit-1/actions/org.freedesktop.devicekit.power.policy

NOW i've got it, but i don't want to reboot.

Thanks for the tip!

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

@brianx

I agree about the need to increase the importance of this bug.

I also have this problem on two of my own machines and one of my customers all of which crash if suspend is used. The only way out then is for them to be turned on the power switch as off as none of the Alt-SysRq sequences work at that point. This is preventing me using it on any other machines at present.

I will try the work round from @stacktracker on my own machines but it needs to be fixed properly before I upgrade any other machines where I have been using gconf-editor to prevent suspend or hibernate.

BavarianPH (bavarianph) wrote :

As of now, this suspend, power-management bug

Is fixed, In the Official Karmic,

and also in Lucid alpha.

Regularly upgrading and updating,

daily, solves many bugs.

Giorgio B. (spudhead85) wrote :

@BavarianPH

Fully updated Karmic and the bug still present... How did you fixed it? Please be more precise...

@Giorgio:

please try:

sudo apt-get install devicekit-power

and then edit:

/usr/share/polkit-1/actions/org.freedesktop.devicekit.power.policy

as shown in the post from stacktracer. That works on my Karmic machine, but
i have no idea if the fix works out of the box on a new/clean Karmic
install. My system is up to date, but i had to use stacktracer's tip to
enable the hibernate in the shutdown menu.

I suffer from this bug in a Karmic freshly installed. I edited the /usr/share/polkit-1/actions/org.freedesktop.devicekit.power.policy as stacktracer said but this is a workaround, not a real solution of this bug. Please confirm (if so) that even unchecking the can_hibernate and can_suspend box you still see the Hibernate and Suspend actions in the shutdown menu.

Martin, this sounds rather painful for our friends in OEM services and certain users are getting a bit stung as well. Could you please look into this (or of course reassign as appropriate). I very much like to see this fixed for Lucid if it is at all feasible.

Changed in gnome-power-manager (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) on 2010-01-12
Changed in gnome-power-manager (Ubuntu):
milestone: none → lucid-alpha-3
status: Confirmed → In Progress
Changed in gnome-power-manager (Ubuntu Karmic):
importance: Undecided → Medium
assignee: nobody → Martin Pitt (pitti)
status: New → Triaged
Changed in oem-priority:
status: New → Triaged
Martin Pitt (pitti) wrote :

So, gnome-power-manager does not actually have those gconf keys (any more). This also makes sense, since this should either be a system-wide policy, or be autodetected from the system whether it's capable of suspending in the first place (see devkit-power --dump, "can-suspend" and "can-hibernate" properties; this part should work fine).

Richard Hughes already proposed to introduce a facility into devkit-power to allow system-wide configuration of whether suspend/hibernate is allowed. This is currently being discussed on devkit-devel@.

Please let me know if that would be okay for you (changing a system-level file instead of a gconf key, which could be easily circumvented anyway).

affects: gnome-power-manager (Ubuntu Lucid) → devicekit-power (Ubuntu Lucid)
Martin Pitt (pitti) wrote :

Changing back to g-p-m for now.

My personal favourite solution is to hide the options in the power management preferences if polkit disallows suspend/hibernate. This would be consistent with expected behaviour and also avoid a new configuration file.

affects: devicekit-power (Ubuntu Karmic) → gnome-power-manager (Ubuntu Karmic)
Daniel Holbert (dholbert) wrote :

@Martin:
> or be autodetected from the system whether it's capable of suspending
> in the first place (see devkit-power --dump, "can-suspend" and
> "can-hibernate" properties; this part should work fine).

This sounds like it'd still present "Hibernate" as an option on computers that have encrypted swap partitions (which intrinsically breaks hibernation). See comment 2 on this bug. We need a solution that lets me *prevent* myself from accidentally hibernating (and triggering unexpected results) on a system with encrypted swap.

If it's possible to auto-detect the encrypted swap and auto-disable hibernation in that situation, that's awesome. But in the absence of that ability, I think there needs to be something user-configurable.

Daniel Holbert [2010-01-19 21:59 -0000]:
> If it's possible to auto-detect the encrypted swap and auto-disable
> hibernation in that situation, that's awesome.

That's in fact what dk-power is already doing in lucid.

Martin Pitt (pitti) on 2010-01-19
summary: - can_suspend and can_hibernate values aren't respected
+ provide a way to disable suspend/hibernate

For the OEM use case we need to be able to disable suspend/hibernate from the user interface without having to patch any packages (adding a new package that contains a gconf key of other standalone configuration file/option is ok).

The devkit-power solution sounds like it might work, provided that all UI components respect those values. For example, in Karmic we have to modify the following to fully remove suspend/hibernate options from the UI:

gdm
gnome-power-manager
gnome-session
indicator-session

I'd like to second Magoun's post. I got two or three calls complaining about
the hibernate function not working. In one of our ISOs I had to make the
hibernate function get the computer in S3 state instead of S4. It would be
great if we could remove the menu option, instead of making workarounds for
the S3/S4 issues.

2010/1/20 Steve Magoun <email address hidden>

> For the OEM use case we need to be able to disable suspend/hibernate
> from the user interface without having to patch any packages (adding a
> new package that contains a gconf key of other standalone configuration
> file/option is ok).
>
> The devkit-power solution sounds like it might work, provided that all
> UI components respect those values. For example, in Karmic we have to
> modify the following to fully remove suspend/hibernate options from the
> UI:
>
> gdm
> gnome-power-manager
> gnome-session
> indicator-session
>
> --
> provide a way to disable suspend/hibernate
> https://bugs.launchpad.net/bugs/432598
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OEM Priority Project: Triaged
> Status in “gnome-power-manager” package in Ubuntu: In Progress
> Status in “gnome-power-manager” source package in Lucid: In Progress
> Status in “gnome-power-manager” source package in Karmic: Triaged
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> System: Ubuntu Karmic alpha6
> gnome-power-manager: 2.27.92.0ubuntu1
>
> The following settings in gconf-editor aren't respected:
> /apps/gnome-power-manager/general/can_hibernate
> /apps/gnome-power-manager/general/can_suspend
>
>
> The problem can be reproduced at least in these three dialogs:
>
> Power Management Preferences:
> Even though suspend or hibernate is disabled, the option is still visible
> as an action.
>
> Shut Down the Computer:
> When I press the shutdown-button on my laptop to enter "interactive-mode",
> both actions are visible, regardless of the gconf-settings.
>
> Indicator-applet-session:
> Both suspend and hiberante shows up, regardless of the gconf-settings.
> (Although this could be a bug in the applet itself. See bug 423608)
>
>
> Other gconf-settings seems to work alright, even if I've changed them to
> non-default values.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/oem-priority/+bug/432598/+subscribe
>

--
Raphael Campos - http://www.optgeek.info/
https://launchpad.net/~optgeek

Martin Pitt (pitti) wrote :

Steve Magoun [2010-01-20 18:40 -0000]:
> For the OEM use case we need to be able to disable suspend/hibernate
> from the user interface without having to patch any packages (adding a
> new package that contains a gconf key of other standalone configuration
> file/option is ok).

Yes, it would mean to ship a new file in /var/lib/polkit-1/localauthority/10-vendor.d/ .

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Earlier gnome-power-manager releases had two gconf keys

  /apps/gnome-power-manager/general/can_hibernate
  /apps/gnome-power-manager/general/can_suspend

to disable suspend/hibernate. Obviously this isn't a very clean approach. It would be much better if upower would actually take the policykit privileges into account for reporting the values to clients, so that gnome-power-prefs, gnome-session, and other clients would do the right thing and hide the suspend/hibernate options if the admin (or an OEM) disables those privileges through a .pkla file, or if the defaults simply change in the future.

Created an attachment (id=33161)
Add up_polkit_is_allowed() function

This is a prerequisite for the following patches:

Add a new polkit helper function up_polkit_is_allowed() which checks whether
the caller has or can get a particular privilege, but without interactive
authentication.

Created an attachment (id=33162)
Add {Suspend,Hibernate}Allowed D-Bus methods

Add two D-Bus server methods to check whether the caller has the privilege to
suspend or hibernate.

We do that on the server side, since that already has everything set up for PolicyKit querying, instead of adding a new dependency and lots of new code to the client side.

Created an attachment (id=33163)
Check PolicyKit in client's can_{suspend,hibernate} properties

Check for PK privileges in UpClient's can_{suspend,hibernate} properties, so
that clients like gnome-session or gnome-power-manager hide the related actions
if the admin or OEM disabled suspend/hibernate through a PolicyKit .pkla file
like

$ cat /etc/polkit-1/localauthority/50-local.d/disable-suspend.pkla
[Disable suspend]
Identity=unix-user:*
Action=org.freedesktop.upower.suspend
ResultActive=no
ResultAny=no

I tested this with both devkit-power --dump and upower --dump, to check that both the old devkit-power-gobject as well as the new libupower-glib work.

The only gotcha with this approach is that the UpClient does not send out property change notifications if the PK privilege is changed, so enabling/disabling suspend/hibernate currently requires a session restart (in the case of long running clients like gnome-session).

Created an attachment (id=33164)
Add {Suspend,Hibernate}Allowed D-Bus methods

Fix previous patch: We do not need to check the kernel capability again, that's already being taken care of.

This patch needs to go after "Add up_polkit_is_allowed() function" and before "Check PolicyKit in client's can_{suspend,hibernate} properties".

In particular, you have to install a file like this for an OEM package:

$ sudo cat /var/lib/polkit-1/localauthority/10-vendor.d/disable-suspend.pkla
[Disable suspend]
Identity=unix-user:*
Action=org.freedesktop.devicekit.power.suspend;org.freedesktop.devicekit.power.hibernate
ResultActive=no
ResultAny=no

If you set this up locally, you should rather put it into /etc/polkit-1/localauthority/50-local.d/ .

Test:

$ pkcheck --action-id org.freedesktop.devicekit.power.suspend --process $$
Not authorized.

summary: - provide a way to disable suspend/hibernate
+ Do not show suspend/hiberate related UI if suspend is disabled in polkit
Martin Pitt (pitti) on 2010-02-08
Changed in gnome-session (Ubuntu Lucid):
status: New → Triaged
Martin Pitt (pitti) wrote :

Ah, gnome-power-manager and the other programs are reading the can_suspend property, so we should just fix that centrally.

affects: gnome-power-manager (Ubuntu Lucid) → devicekit-power (Ubuntu Lucid)
Changed in gnome-session (Ubuntu Karmic):
status: New → Invalid
Changed in gnome-session (Ubuntu Lucid):
status: Triaged → Invalid
Changed in indicator-applet (Ubuntu Karmic):
status: New → Invalid
Changed in indicator-applet (Ubuntu Lucid):
status: New → Invalid
Martin Pitt (pitti) wrote :

Further analysis showed that it's not possible to add a policykit check into the can_{suspend,hibernate} properties. This needs changing the DK-P D-Bus API to replace the properties with method calls, check PolicyKit in those method calls, wrapping the new D-Bus call into a new libdevkit-power-gobjec and rewire the clients (gnome-session, indicator-applet, gnome-power-prefs) to use the new method instead of the gobject property.

This is therefore not SRUable, it's way too intrusive.

Changed in gnome-power-manager (Ubuntu Lucid):
status: New → Triaged
Changed in devicekit-power (Ubuntu Karmic):
assignee: Martin Pitt (pitti) → nobody
status: Triaged → Won't Fix
Changed in gnome-power-manager (Ubuntu Karmic):
status: New → Won't Fix
Changed in gnome-session (Ubuntu Karmic):
status: Invalid → Won't Fix
Changed in gnome-session (Ubuntu Lucid):
importance: Undecided → Low
status: Invalid → Triaged
Changed in indicator-applet (Ubuntu Lucid):
importance: Undecided → Low
status: Invalid → Triaged
Changed in indicator-applet (Ubuntu Karmic):
status: Invalid → Won't Fix
Changed in devicekit-power:
status: Unknown → Confirmed
Martin Pitt (pitti) wrote :

Patches sent upstream for review (already discussed with Richard on IRC, should be okay).

I managed to do this in a way which remains compatible with the previous API, so we do not need to fix gnome-session and g-p-m after all. indicator-applet seems to do something funky and not use DkpClient, so this still needs fixing.

Changed in devicekit-power (Ubuntu Lucid):
status: In Progress → Fix Committed
Changed in gnome-session (Ubuntu Lucid):
status: Triaged → Invalid
Changed in gnome-session (Ubuntu Karmic):
status: Won't Fix → Invalid
Changed in gnome-power-manager (Ubuntu Lucid):
status: Triaged → Invalid
Changed in gnome-power-manager (Ubuntu Karmic):
status: Won't Fix → Invalid

Looks good to me, please commit!

Changed in devicekit-power:
status: Confirmed → Fix Released

On Lucid, it would seem the /etc/polkit-1/* folders are not used.

Puting a power.conf file:

[Disable suspend]
Identity=unix-user:*
Action=org.freedesktop.devicekit.power.suspend
ResultActive=no
ResultAny=no

[Disable hibernate]
Identity=unix-user:*
Action=org.freedesktop.devicekit.power.hibernate
ResultActive=no
ResultAny=no

[Disable shutdown]
Identity=unix-user:*
Action=org.freedesktop.consolekit.system.stop
ResultActive=no
ResultAny=no

In:
 - /etc/polkit-1/localauthority/50-local.d
 - /etc/polkit-1/localauthority.conf.d

Does NOT affect the applied policy (cf. pkcheck and Gnome shutdown dialog)

Modifying the /usr/share/polkit-1/actions/* files DOES lead to the expected results (cf. pkcheck and Gnome shutdown dialog)

Am I:
 - missing something (like reloading a daemon somewhere)
 - or is this a bug; a sysadmin would expect his custom settings to be in /etc/polkit-1 and be honored (and not be erased by some package update) ?

Scratch my previous comment.

The /etc/polkit-1/localauthority/*.d files ARE honored, provided the files are named *.pkla

Sorry

Martin Pitt (pitti) wrote :

upower (0.9.0+git20100216.72bb2-0ubuntu1) lucid; urgency=low

  Same version as the -1 upload to Debian experimental, but needs to clear NEW
  still.

  [ Martin Pitt ]
  * New upstream release, and updating to current git head:
    - Rename the project, library, and D-Bus interface to upower.
    - Bug fixes.
    - Translation updates.
    - Set client library's can_{suspend,hibernate} properties to False if
      suspend/hibernate is prohibited through PolicyKit. (LP: #432598)
  * Drop 01-lid-status-fallback.patch, 02-dkpclient-singleton.patch: Applied
    upstream.
  * debian/rules, debian/control: Add an epoch to the transitional
    devicekit-power-doc package, so that the upgrade will actually work.
  * debian/rules: Explicitly enable gtk-doc building, upstream configure
    disables that now.
  * Build libdevkit-power-gobject{1,-dev} packages, but mark them as obsolete.
    These are still necessary, until upowerd is fully ported to the new
    libupower-glib.

  [ Michael Biebl ]
  * debian/upower.install: Only install upower and upowerd, not the
    transitional symlinks.
  * debian/control: Bump Standards-Version to 3.8.4. No further changes.

 -- Martin Pitt <email address hidden> Tue, 16 Feb 2010 10:16:24 +0100

affects: devicekit-power (Ubuntu Lucid) → upower (Ubuntu Lucid)
Changed in upower (Ubuntu Lucid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

I ported indicator-session from DeviceKit-power to libupower-glib, which will also fix this bug. I'll send a merge proposal now.

affects: indicator-applet (Ubuntu Karmic) → indicator-session (Ubuntu Karmic)
Changed in indicator-session (Ubuntu Lucid):
status: Triaged → In Progress
assignee: nobody → Martin Pitt (pitti)
Kjell L. (lkjell) wrote :

Looks like I can disable hibernation and suspend in /usr/share/polkit-1/actions/org.freedesktop.upower.policy now. Running lucid

Alkis Georgopoulos (alkisg) wrote :

I tried to disable suspension of my laptop using the methods described in comments #28 (Martin Pitt), #32 (Cédric Dufour) and #36 (Kjell L.), but I was unable to. I rebooted after trying each method, but suspension always worked from the indicator-session menu.

pkcheck --action-id org.freedesktop.devicekit.power.suspend --process $$
Not authorized.

What am I doing wrong? Or is indicator-session not ready yet?

Alkis Georgopoulos [2010-02-21 9:15 -0000]:
> I tried to disable suspension of my laptop using the methods described
> in comments #28 (Martin Pitt), #32 (Cédric Dufour) and #36 (Kjell L.),
> but I was unable to. I rebooted after trying each method, but suspension
> always worked from the indicator-session menu.

It shouldn't "work"; If you set up the .plka file correctly, it should
merely lock the screen, not suspend.

> What am I doing wrong? Or is indicator-session not ready yet?

It isn't, that's why the indicator-session task here is still open.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt (pitti) wrote :

My indicator-session branch was rejected

Changed in indicator-session (Ubuntu Lucid):
assignee: Martin Pitt (pitti) → nobody
status: In Progress → Triaged
assignee: nobody → Indicator Applet Developers (indicator-applet-developers)

I've been pulling my hair out on this one today on a lucid test system, wondering why I couldn't get the parts that should work working. Finally realized that it was a simple mistake, but thought I'd point it out here in the hopes that it will save someone else some time.

In *lucid*, the policykit "actions" have changed. They used to be org.freedesktop.devicekit.power.* but are now org.freedesktop.upower.*

So, Martin's example in #28 goes like this on lucid:
$ sudo cat /etc/polkit-1/localauthority/50-local.d/disable-suspend.pkla
[Disable suspend]
Identity=unix-user:*
Action=org.freedesktop.upower.suspend;org.freedesktop.upower.hibernate
ResultActive=no
ResultAny=no

$ pkcheck --action-id org.freedesktop.upower.suspend --process $$
Not authorized.

Once this change is made, everything's happy, except for the Indicator applet, which is still an open issue.

Martin Pitt (pitti) wrote :

Matthew L. Dailey [2010-03-01 22:53 -0000]:
> In *lucid*, the policykit "actions" have changed. They used to be
> org.freedesktop.devicekit.power.* but are now org.freedesktop.upower.*

Confirmed.

> Once this change is made, everything's happy, except for the Indicator
> applet, which is still an open issue.

Correct. My libupower-glib branch (which would fix this) was rejected,
because it does not meet the coding guidelines for indicator (so
ignore this branch). The indicator applet needs to ask upower for
HibernateAllowed() or SuspendAllowed().

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Ted Gould (ted) wrote :

I don't understand why we should be removing the items on the menu if there is administrator privlidges required to do the action. It would seem that they should switch to a "Sleep..." but you should still be allowed to ask the machine to sleep and give your password. As I understand it, this is what the "Allowed" function check.

But, there are two other properties that are in upower that allow for setting whether the machine CanSuspend or CanHibernate. These are derived by catting /sys/power/state and looking to see if it contains "mem" and/or "disk." I believe that these are derivated from the drivers in the system saying what they in turn support.

CanSuspend and CanHibernate are checked in indicator-session.

Martin Pitt (pitti) wrote :

Ted Gould [2010-03-08 19:27 -0000]:
> I don't understand why we should be removing the items on the menu if
> there is administrator privlidges required to do the action. It would
> seem that they should switch to a "Sleep..." but you should still be
> allowed to ask the machine to sleep and give your password. As I
> understand it, this is what the "Allowed" function check.

No, it checks whether you either already have or can get the privilege
(via entering your password) to suspend. If it says "no", it means
"no, you can't get it". Administrators who want to disable
suspend/hibernate would set this in the .pkla file.

> But, there are two other properties that are in upower that allow for
> setting whether the machine CanSuspend or CanHibernate. These are
> derived by catting /sys/power/state and looking to see if it contains
> "mem" and/or "disk." I believe that these are derivated from the
> drivers in the system saying what they in turn support.

Right, but those mean "the kernel says it's able to", which is
different from "PolicyKit says the user is allowed to". So we need to
check both.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

David Barth (dbarth) wrote :

Linking to the upstream project to get it under the end of cycle radar. The distinction between HW support & PK policy should help find a solution.

Changed in indicator-session:
assignee: nobody → Ted Gould (ted)
importance: Undecided → Medium
milestone: none → ubuntu-10.04-beta-1
status: New → Triaged
Ted Gould (ted) on 2010-03-16
Changed in indicator-session:
status: Triaged → Fix Committed
milestone: ubuntu-10.04-beta-1 → 0.2.6
Ted Gould (ted) on 2010-03-18
Changed in indicator-session:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-session - 0.2.6-0ubuntu1

---------------
indicator-session (0.2.6-0ubuntu1) lucid; urgency=low

  * Upstream release 0.2.6
    ∘ Updating sessions to make guest account marked when being
      used (LP: #436030)
    ∘ String "Switch From" is miscapitalized (LP: #540265)
    ∘ Follow user switching lockdown key (LP: #504360)
    ∘ Use user avatar images in session menu (LP: #436028)
    ∘ Don't show suspend/hibernate if disabled in Policy Kit (LP: #432598)
    ∘ Lock screen when switching users (LP: #536801)
    ∘ Fix callback prototype (LP: #536990)
    ∘ Revert back to "Shut Down" instead of "Switch Off" (LP: #540056)
    ∘ Fix leaked GConf notifications
    ∘ Add GConf key for showing the "Log Out" item
    ∘ Adding the ability to specify a desktop file to have at the end
      of the menu.
    ∘ Setting up restart required notification by changing panel icon
      and icon in menus.
    ∘ Use the libindicator image helpers
    ∘ Set proper translation domain for loadable indicator
    ∘ Translation update
  * debian/control: Require libindicator 0.3.5
 -- Ted Gould <email address hidden> Thu, 18 Mar 2010 14:22:41 -0500

Changed in indicator-session (Ubuntu Lucid):
status: Triaged → Fix Released
Jerone Young (jerone) on 2010-03-25
Changed in oem-priority:
status: Triaged → Fix Released
Dang Kang (kangdang) on 2010-04-02
Changed in upower (Ubuntu Karmic):
status: Won't Fix → Confirmed
Omer Akram (om26er) wrote :

Please dont change the status of bug if you dont know what you are doing

Changed in upower (Ubuntu Karmic):
status: Confirmed → Won't Fix
Changed in devicekit-power:
importance: Unknown → Medium
Changed in devicekit-power:
importance: Medium → Unknown
Changed in devicekit-power:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.