Bug 870220 - Cancel in Authentication Required Dialog Box when performing Restart or Power Down from users desktop with multiple uses logged in kicks out of user session
Summary: Cancel in Authentication Required Dialog Box when performing Restart or Power...
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-10-25 20:15 UTC by smatula
Modified: 2014-02-05 12:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-02-05 12:43:45 UTC
Type: Bug

Attachments (Terms of Use)

Description smatula 2012-10-25 20:15:29 UTC
Description of problem:
Cancel restart/power off from user session, when asked for admin password kicks user out of session.

Version-Release number of selected component (if applicable):
Fedora-18 Beta TC6

How reproducible:
Every time

Steps to Reproduce:
1.gdm Logon for user1
2.Desktop of user1 perform Switch User to user2. Menu item under user name top right
3. From user2 desktop perform power off from menu under user name.
4. click either restart or power off
5. Authentication dialog displayed.
6. click cancel
Actual results:
Dialog displayed again.
Click cancel again and it exits the session. At locked screen of user1

Expected results:
On first cancel expect to exit back to user2's desktop

Additional info:

Comment 1 Matthias Clasen 2012-10-31 02:17:47 UTC
I can confirm this.

Comment 2 Matthias Clasen 2012-10-31 02:31:13 UTC
This is not an easy fix; it involves redesigning the session-end handling in gnome-session and interleave it with logind communication. 

See https://bugs.freedesktop.org/show_bug.cgi?id=24493 for an earlier attempt to implement this for ConsoleKit, which sadly went nowhere.

Comment 3 Ray Strode [halfline] 2012-10-31 02:39:47 UTC
The problem is the polkit dialog presented after the session is pretty much torn down.  logind is the one initiating the polkit dialog, though.  Ideally we'd have a logind api to do just the polkit bit first, ahead of time, and then we could follow through with the actually shut down at the place in the code we do it now.

One less than ideal fix is to query polkit ourselves at a time that's good for us and rely on the cached credentials from that invocation to carry us through when logind would ask.  That won't work for all configurations, though, and we'd have to guess the polkit action logind is going to use.  Right now it has several it uses depending on what was requested and what sessions are around.

Comment 4 Matthias Clasen 2012-10-31 09:47:10 UTC
Here is my idea:

when 'power off' is clicked in the power off dialog, we

 - take a shutdown delay inhibitor
 - call PowerOff(True)

there are two possible outcomes:

 a) the PowerOff call returns an AccessDenied error

 b) we get a PrepareForShutdow signal (if there was not polkit dialog, or the
    user got permission to go ahead

all of this is still in the query end session phase

in the first case, we hide the power off dialog, drop the delay inhibitor, and go back to the running phase

in the second case, we go through the end session phase before hiding the power off dialog and dropping the delay inhibitor, which will let systemd proceed with the shutdown

note that the extra complication with the inhibitor is only strictly necessary if CanPowerOff returns 'challenge'. if it returns 'yes', we can follow the current code path of first going through the end session phase and only calling PowerOff at the very end, when there's no way back anymore.

Comment 5 Jaroslav Reznik 2012-10-31 11:43:52 UTC
Well if this affects the ability to shutdown/restart, it will hit "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work" criteria but (and from description it seems so) it happens only when the action is canceled in polkit dialog. So from this POV it's more NTH, not a blocker.

Comment 6 Kamil Páral 2012-10-31 11:59:58 UTC
Yes, this is an annoying bug, but no way a blocker.

smatula, do you really believe we wait with releasing F18 Beta (or Final) until this bug is fixed? If you really feel strongly about it, please feel free to propose it as a blocker again. In the meantime I'm removing the blocker tag.

Comment 7 Matthias Clasen 2012-10-31 12:14:28 UTC
Also note that this has never worked any better before.
It is not a new problem; the ck patchset I'm referring to above is from 2010

Comment 8 Matthias Clasen 2012-11-01 01:00:57 UTC
Lennart confirmed that the idea in comment 4 should work as stated.

Comment 9 Matthias Clasen 2012-11-11 04:29:12 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=688076 has an implementation.

Comment 10 Fedora End Of Life 2013-12-21 09:12:18 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Fedora End Of Life 2014-02-05 12:43:48 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.