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
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
Dialog displayed again.
Click cancel again and it exits the session. At locked screen of user1
On first cancel expect to exit back to user2's desktop
I can confirm this.
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.
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.
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.
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.
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.
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
Lennart confirmed that the idea in comment 4 should work as stated.
https://bugzilla.gnome.org/show_bug.cgi?id=688076 has an implementation.
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.
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.