Consolekit / Policykit interaction with indicator-applet-session produces unexpected results

Bug #459705 reported by QPrime
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
consolekit (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: indicator-applet

Expected result:
Shutting down or rebooting via the indicator-applet-session applet with other users logged into the system should either produce the expected action or return the state to its prior state on authentication failure or cancelation.

Actual result:
Shutting down or rebooting via the indicator-applet-session applet with other users logged into the system will result in a policykit dialogue after the user has approved the selection action via the indicator-applet-session applet dialogue. If the user cancels the policykit action (perhaps due to the previously unknown login) the current users' X session will be dumped and restarted - an unsuspecting user might consider this a rather naughty and unexpected action.

Steps to reproduce:
1) Login to two sessions (one X session and one VTY session)
2) Select Shut Down or Restart from the indicator-applet-session applet menu
3) Approve the selected action from the indicator-applet-session applet dialogue box
4) Select Cancel at the following policykit dialogue box
5) Behold as your X session is terminated with extreme prejudice

Possible solutions:
1) Inform the user of additional logins and request authorization with via policykit *before* obtaining approval via the indicator-applet-session applet dialogue box.
2) Integrate policykit user notification/authentication and indicator-applet-session notification/authorization into one dialogue.
3) Don't end the current X session, but instead return control of the current X session back to the user so that he/she can investigate the situation.

ProblemType: Bug
Architecture: i386
Date: Sat Oct 24 07:04:14 2009
DistroRelease: Ubuntu 9.10
Package: indicator-applet-session 0.2.0-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: indicator-applet
Uname: Linux 2.6.31-14-generic i686

Revision history for this message
QPrime (mwells) wrote :
Revision history for this message
Ted Gould (ted) wrote :

100% agree. This is a bug in the interaction between console-kit and policy-kit and there isn't much we can do about it at the indicator-applet level.

affects: indicator-applet (Ubuntu) → consolekit (Ubuntu)
Revision history for this message
QPrime (mwells) wrote :

Thanks for the redirect Ted.

QPrime (mwells)
summary: - Policykit interaction with indicator-applet-session produces unexpected
- results
+ Consolekit / Policykit interaction with indicator-applet-session
+ produces unexpected results
Revision history for this message
QPrime (mwells) wrote :

Still experiencing this with Lucid daily live (built on 2010.02.13) - fully patched as of 2010.02.19, with the following caveats...

1) An active VTY session using the same account as used for the GDM login will *not* stop shutdown. The VTY is simply crushed during shutdown.

2) An active VTY session with a different active login (e.g. an "sudo su") will prompt for credentials, but results in the behavior described in the original post (i.e. X session is killed).

3) A terminal window via Gnome (even a terminal window with an active "sudo su" login) will *not* stop shutdown.

While I am ambivalent as to the correct handling of extra logins via Gnome (e.g. terminal "sudo su") I feel pretty strongly about VTY logins. Any VTY login, either same user or different user (e.g. via "sudo su"), should prompt the Gnome user requesting the shutdown for authorization to proceed. A user sophisticated enough to initiate a VTY login can cleanly take care of the issue when notified of multiple logins on shutdown. I think there is a case to be made for consistent action with Gnome terminal logins as well (specifically terminals logged in as an alternate user) but I *do* want my desktop to shutdown when requested, without jumping through hoops. Opinions on this will vary I'm sure. I have not tested this via telnet, ssh, etc - only from the VTYs

*However*, the killing of the X session on cancel remains a serious problem in any scenario.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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