Shutdown from greeter does nothing when multiple accounts open

Reported by Robert Ancell on 2011-09-28
586
This bug affects 125 people
Affects Status Importance Assigned to Milestone
LightDM GTK+ Greeter
Medium
Unassigned
OEM Priority Project
High
Ara Pulido
Precise
High
Ara Pulido
Unity Greeter
Medium
Unassigned

Bug Description

[Impact]

 * A user tries to shut down their machine. They get confused because nothing happens
   when they click shutdown.
 * If someone else is logged in, they will have to ask that person to "Switch User" to
   log in and log out
 * If someone else is logged in and you don't know the password of the account, you
   can't shut down

[Test Case]

 * Have two login accounts
 * Log both people in, via power cog->lock screen->switch user
 * lock the screen on current account, via power cog->lock screen
 * get back to lightdm via switch user
 * log in to an already logged in account, and try to power off the machine

[Regression Potential]

 * It wasn't possible to shutdown at all before
 * I can't see a case for a regression, since it never worked to begin with

[Original Report]

Selecting shutdown from the greeter does nothing when multiple accounts are open.

This is because the lightdm user (which the greeter runs as) does not have permission to shutdown while sessions are open. Inside a normal session this would just return you to the login screen.

The solution is either for the indicator to say "not allowed" or to run a PolicyKit frontend in the greeter than can get the required permissions to perform the shutdown.s

Related branches

lp:~robert-ancell/indicator-session/lp-861171
Mathieu Trudel-Lapierre: Resubmit on 2013-04-16
Matthew Paul Thomas: Approve (design) on 2013-03-18
PS Jenkins bot: Approve (continuous-integration) on 2013-01-11
Changed in unity-greeter (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Changed in unity-greeter:
status: New → Triaged
importance: Undecided → Medium
Changed in lightdm:
status: New → Triaged
importance: Undecided → Medium
Sebastien Bacher (seb128) wrote :

somewhat related to bug #855556

affects: lightdm → lightdm-gtk-greeter
Changed in indicator-session:
status: New → Triaged
importance: Undecided → Medium
Sebastien Bacher (seb128) wrote :

bug #838792 tracks similar issues as well

f_padia (f-padia) wrote :

you do not even have to be logged into multiple user accounts. On my laptop I cant shutdown/restart if I am even logged into 1 account. Bit silly that not even a message pops up to say "cannot shut down because...".
I think this is a serious usability issue. If there were concerns that the dodge behaviour of the launcher was confusing to new users then this behaviour of the unity greeter will cause new users to lose their minds.

BlueCase (bluecase) wrote :

Hi,
I think this bug should get a higher priority because of its very confusing specially for new Ubuntu Users.
Users which don't realize why they can't shutdown the system will try to force it and the only way which the most know is to press and hold the PowerButton. Data loss possible...
FIrst step should be a information window which inform the User in the LightDM Session that the system couldn't shutdown because other Users are logged on and also inform about which users are affected.
Or we make in the System Indicator everywhere the Shutdown entry in this situation unusable and rename it to: "Shutdown - 2 Active Users"

In a second step it should be possible anyway to run a PolicyKit dialog to force the shutdown.

regards,
BlueCase

Sebastien Bacher (seb128) wrote :

> I think this bug should get a higher priority because of its very confusing specially for new Ubuntu Users.

Right, everybody agrees that the issue is annoying, but the bug is not fixed yet is due to lack of manpower (and the fact that the bug is not that trivial to fix), not because the settings were not set higher, setting to High but it's not going to automagically resolve the issue...

Changed in indicator-session:
importance: Medium → High
Changed in indicator-session (Ubuntu):
importance: Undecided → High
status: New → Triaged
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/861171

tags: added: iso-testing
mindbox (mindbox) on 2012-05-30
Changed in gnome-session (Ubuntu):
status: New → Confirmed
status: Confirmed → New
status: New → Confirmed
status: Confirmed → New
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-session (Ubuntu):
status: New → Confirmed
Changed in policykit (Ubuntu):
status: New → Confirmed
v4169sgr (andrew-d-scott-uk) wrote :

Affects me also as a 64 bit install of 12.04 with four user accounts. A warning and a password over-ride should be generated, as per behaviour in 10.04. As it stands non-admin user cannot now shut down normally at all if another user is logged in, even if the other user's processes are in 'zombie' state.

Data loss and / or system damage definitely possible.

Matthew Paul Thomas (mpt) wrote :

This bug report is about "Selecting shutdown from the greeter". Bug 621714, bug 660120, bug 747330, bug 855556, and bug 872054 have all been marked as duplicates but they all specifically mention trying to shut down or restart from inside a session. Either this bug report is overly precise, or those five reports are not duplicates.

Daniel Richard G. (skunk) wrote :

Can you tell who marked those bugs as duplicates? If it wasn't Robert Ancell, they could probably be unmarked. There's a possibility the same codepath is involved in being at the greeter vs. in a session, but he's likely the only person active here who would know for sure.

Lionel Le Folgoc (mrpouit) wrote :

That wasn't Robert (you can check by appending /+activity to each bug url).

parq (pablo-romeroquinteros) wrote :

@Matthew,
At least bug #855556 seems to have the same core problem.

I've published a workaround in bug #855556 that i'm going to copy here, and fix this bug (#861171) and bug #855556.

I think the problem is only related to PolicyKit, because this doesn't handle correctly the 'auth_admin_keep' directive. When an admin user try to halt/restart the system, this directive may ask for admin password an allow only to admin users to halt/restart the system.

The workaround goes through modify the 'auth_admin_keep' to 'yes', which allow to any user (admin o desktop user) to halt/restart the system.

This is not a full solution, but may be a step forward.

parq (pablo-romeroquinteros) wrote :

Workaround:

As I've commented previously, this partial solution is to modify this file:

/usr/share/polkit-1/actions/org.freedesktop.consolekit.policy

and change:

auth_admin_keep

to:

yes

Edit the file /usr/share/polkit-1/actions/org.freedesktop.consolekit.policy using your favorite text editor. You will need root permissions.

Change the section relating to shutdown when others are logged in from

  <action id="org.freedesktop.consolekit.system.stop-multiple-users">
    <description>Stop the system when multiple users are logged in</description>
    <message>System policy prevents stopping the system when other users are logged in</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

to

  <action id="org.freedesktop.consolekit.system.stop-multiple-users">
    <description>Stop the system when multiple users are logged in</description>
    <message>System policy prevents stopping the system when other users are logged in</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

and the section relating to rebooting when others are logged in from

  <action id="org.freedesktop.consolekit.system.restart-multiple-users">
    <description>Restart the system when multiple users are logged in</description>
    <message>System policy prevents restarting the system when other users are logged in</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

to

  <action id="org.freedesktop.consolekit.system.restart-multiple-users">
    <description>Restart the system when multiple users are logged in</description>
    <message>System policy prevents restarting the system when other users are logged in</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

And that will allow you (any user) shutdown and reboot the PC when multiple users are logged in. Whether you want to do that is a different question.

Source: http://askubuntu.com/questions/1190/how-can-i-make-shutdown-not-require-admin-password

parq (pablo-romeroquinteros) wrote :

I see this bug has triaged a lot of packages/apps.

I think this is a PolicyKit only behavior, and could be some related issue with greeter (lightdm o gnome) related on how to handle the request of admin password from PolicyKit.

The rest of packages/apps should be, imho, freed from this bug.

parq (pablo-romeroquinteros) wrote :

También he publicado cómo resolver este problema en español:

http://elblogdeparq.blogspot.com.es/2012/08/ubuntu-no-se-puede-reiniciarapagar-si.html

Florian Diesch (diesch) wrote :

@parq: I'd prefer to get an error message that tell me why I can't shut down with an option to shut down anyway. Just shutting down may lead to data loss so that's usually not what I want.

parq (pablo-romeroquinteros) wrote :

@Florian,

You're right!! This isn't a full solution.

It's only a workaround for those (like me) that want a partial solution and accept the (high) risk.

As I have said in a previous comment (https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/861171/comments/13) the full solution is that where PolicyKit will be working correctly and asking only to admin users if they really want to halt/reboot the system.

Until that time, now you can choose.

Regards,

ethanay (ethan-y-us) wrote :

so, to recap:

1. user should get communication from OS regardless of whether they are admin
a. normal users should get a message explaining why restart / shut down has failed (because other users are still logged in; otherwise it just looks like unexpected behavior)
b. admin users should get a message explaining that other users are logged in and restart / shut down will log them out and lose any unsaved work

?

parq (pablo-romeroquinteros) wrote :

@ethanay

I agree with you.

This is just an example of the expected behavior, imho:

a. Normal user + other users logged:
"You just can't turn off the computer because there are more users logged. Please talk to an admin." [ok]

b. Admin user + other users logged:
"There are more users logged in the system. Are you sure?" [Yes/No]

With only 1 user logged (normal or admin) don't ask and shutdown.

Regards,

Am Mon, 01 Oct 2012 21:36:26 -0000
schrieb parq <email address hidden>:

> @ethanay
>
> I agree with you.
>
> This is just an example of the expected behavior, imho:
>
> a. Normal user + other users logged:
> "You just can't turn off the computer because there are more users
> logged. Please talk to an admin." [ok]
>
> b. Admin user + other users logged:
> "There are more users logged in the system. Are you sure?" [Yes/No]

Sounds good. A bonus would be to list the users if only a few are
logged in and give the number otherwise

--
Plugin for Nautilus to create and modify application
starters (.desktop files):
<http://www.florian-diesch.de/software/arronax/>

parq (pablo-romeroquinteros) wrote :

@Florian,

Nice idea!!

Some examples for the notification if there are some users are logged:

"You and Florian are logged."

"You, Florian, ethanay, daniel, Lionel and 3 more are logged."

Ernst Sjöstrand (ernstp) wrote :

Why are you talking about notifications and password prompts, the computer should shut down (by default) of course!
It could prompt and say "X is logged in, are you really sure you want to shut down?" but nothing more. If an admin wants to disable it there should be a way to do that instead.
Let's say I'm logged in but I'm not at home and my wife wants to shut down the computer. Of course she should be allowed to!

Therefore I think setting org.freedesktop.consolekit.system.stop-multiple-users to allow_active=yes is a great and correct solution. What's missing there is a local override solution so and admin of a multi-seat server could turn it off for example without having it overwritten everytime policykit updates.

bwat47 (bwat47) wrote :

@Ernst Sjöstrand (ernstp)

That's pretty much what everyone else is already saying: By default when you shutdown with other users logged in, it should prompt saying other users are logged in, are you sure?, and then let you shutdown if you hit ok. The other suggestions here are just ways to make that even more user friendly, such as telling you exactly who is logged in etc...

The prompt is very necessary, since shutting down with other users logged in can cause data loss, so the user must be informed of this before continuing with the shutdown. This is the same behavior windows 7 uses by default and it does work well :)

parq (pablo-romeroquinteros) wrote :

Ernst,

If you follow the comments you'll figure out that some time the computer should shut down and some time it shouldn't, depending on the user requesting the shut down and the amount of users logged in.

After some comments, we're proposing some ideas of how it could be shown or communicated to the user / admin that is requesting the action.

The examples of my last comment has to be connected with the others examples of previous comments, then having this result, for instance:

"You, Florian, ethanay, daniel, Lionel and 3 more are logged."
"You just can't turn off the computer because there are more users logged. Please talk to an admin." [ok]

(this is the case where a user request a shut down when the are 8 people logged in)

---

Anyway, the case you say in your comment has been commented before, and the main idea is that your wife will be able to shut down the system in the following cases:
- She is an admin
- She is an user and is the only one logged in the computer

---

Your proposal related to org.freedesktop.consolekit.system.stop-multiple-users, as far as I know, allow to any user to shut down the system (please correct me if I'm wrong). This solution was discussed as a preliminary workaround, until this bug had been corrected properly.

Matthew Paul Thomas (mpt) wrote :

I used this particular problem as an example when redesigning the PolicyKit prompt. <https://wiki.ubuntu.com/AccountPrivileges#The_prompt> (In that sketch I also show fingerprint authentication, but you can ignore that part.)

Jamie Chang (jamie315) on 2012-11-06
Changed in oem-priority:
importance: Undecided → High
Marius B. Kotsbak (mariusko) wrote :

And in the case that yourself is logged in at the console, no admin password should be asked. I think kdm handles this better.

Changed in oem-priority:
status: New → In Progress
tags: added: rls-r-incoming
ethanay (ethan-y-us) wrote :

why can't the greeter just say, "X user(s) is/are still logged in. Please log out of all accounts before attempting to shut down or reboot." and ignore all the nastly permissions stuff??

If an admin really needs to shut down, it's easy enough to do via terminal or tty. are there really daily use cases where a standard user needs permission to shut down if other accounts are still logged in?

i think we should also consider whether those "other accounts" are most likely to be guest sessions, anyways...

parq (pablo-romeroquinteros) wrote :

@Marius,

Maybe kdm handles it better. That's why we're asking for improve this feature in lightdm.

parq (pablo-romeroquinteros) wrote :

@ethanay,

Terminal or tty shouldn't be the only way to solve this problem. There's a lot of people that hasn't this knowledge. And request that the system does what it seems to be doing (but it doesn't) is, imho, the simple way to solve it.

Regards,

parq (pablo-romeroquinteros) wrote :

@Matthew,

Your approach related to the prompt / secondary text seems to be fine.

In addition, more information related to other users logged before halt or reboot could be useful. You can see some examples at comments #20 and #22. By the way, I'm not so sure if this behavior is about policykit or lightdm...

parq (pablo-romeroquinteros) wrote :

@Matthew,

Maybe you should add what we were talking about in this bug:

Allow to a 'no admin user' to shutdown/reboot the system if he/she is the only user logged in.

Kind Regards,

James M. Leddy (jm-leddy) wrote :

Anyone that is interested in a workaround can pick up a new policykit policy here:

https://launchpad.net/~canonical-hwe-team/+archive/sputnik-policykit

Kai Mast (kai-mast) wrote :

This also happens when you choose to shutdown inside a session and another user is logged in. Then instead of shutting down you are only logged out.

This really sucks. Because I trust my computer to shutdown when I click shutdown. So sometimes I leave the room after shutting down and returns hours later and realize it is still running :(

James M. Leddy (jm-leddy) wrote :

Just got done corresponding with seb128 about this, Robert Ancell said patching the indicator to warn about other logged users should fix the most common cases and not be too hard.

Robert Ancell (robert-ancell) wrote :

The solution I have implemented in lp:~robert-ancell/indicator-session/lp-861171 resolves this issue by changing the session indicator to disallow shutdown or restart if more than one session is open.

This resolves the greeter issue:
old: Shutdown/restart silently failed.
new: Information dialog appears "You need to close all sessions before restarting"

This changes the session behaviour:
old, non-administrator user: PolicyKit dialog appears prompting for administrator password, on authentication system is shutdown immediately, otherwise sessions is logged out.
old, administrator user: Shutdown/restart occurs immediately without any warning
new: Dialog appears saying "You need to close all sessions before restarting" and gives option to log out instead.

This doesn't resolve the following issues:
- Pressing the power button in the greeter doesn't show a dialog
- Pressing the power button in the session doesn't warn about other sessions being open (this dialog is from gnome-session). The behaviour is the same as in the old, non-administrator user case above.
- This means using the mouse you cannot do a system administrator override shutdown when multiple sessions are open. I don't see this as being a major problem as system administrators have other non-GUI methods of accessing this, you can still do this by pressing the power button (see above) or holding by power cycling.

I think this change is a marked improvement on what we have, and we can continue to track improvements in other bugs. Given this I will close out the other bug tasks not related to this solution.

Robert Ancell (robert-ancell) wrote :

After writing the previous comment I realised we can just have the behaviour change in the greeter and not in the session if we want.

I think it is better with this solution though because:
- The dialog is more consistent between session and greeter
- The current PolicyKit dialog is bad because cancelling it closes your session - i.e. accidentally bumping the power button puts you in a situation where you session will close regardless of what you do.
- Shutting down without closing a session is a very destructive operation - it is better to encourage the user to close each session manually [*] to avoid data loss. Knowledgeable sysadmins can do a forced shutdown by other methods and inexperienced users probably know how to power cycle.

mpt/design, can you comment on the above?

I propose we use this solution in raring and just push the greeter behaviour into SRUs for 12.04, 12.10.

[*] We should probably make it possible to unlock sessions in the greeter with an administrator password so this is easily possible.

Marc Deslauriers (mdeslaur) wrote :

I have a slight issue with this design...it's encouraging people who are on the console to force a power off if they don't care/don't have the credentials of the other active sessions. Shouldn't we give the possibility of still obtaining a policykit dialog to force shutdown? Possibly something like a "Shutdown anyway" button?

Marc Deslauriers (mdeslaur) wrote :

Actually, the policykit dialog should give sufficient rights to whoever's at the console, not just system administrators. There is no reason to ask for authentication to shut down a machine when someone's on the console and presumably has access to the power button.

Matthew Paul Thomas (mpt) wrote :

It's a toss-up: the current behavior is mysterious, but the proposed behavior would be vexatious. Ubuntu would be telling you that the other accounts need to log out, but refusing to offer to do that.

I don't feel strongly about whether it should require admin-only authentication or any-user authentication. The important thing is to have a confirmation step making it clear that forcing logouts of other users is Serious Business.

bwat47 (bwat47) wrote :

I agree that there isn't much point in limiting who should be able to shut down the machine when accounts are logged in, when the user has access to the power button anyway. I feel that any user should always have the opportunity to "cleanly" shut down the machine via the GUI, not allowing that is a big usability issue. Ubuntu should first warn that other users are logged in, and the offer to shut down anyway, regardless of their account status.

For a more long-term goal, it would be nice if ubuntu offered to log the accounts out for you, and in doing so saved the sessions of the logged in accounts, so no work is lost when the machine is shut down, but it would probably require a lot of work to make that a possibility. In the mean time, simply giving a clear warning that work will be lost if the machine is shut down while users are logged in, and then letting the user click shutdown is sufficient.

Jamie Strandboge (jdstrand) wrote :

I would argue the current behavior is both mysterious and vexatious. Ubuntu tells you nothing and refuses to do what you told it to do.

Steve Langasek (vorlon) wrote :

For the record, it's not actually true that any user with a graphical login will be in a position to reach the power button. Rebooting the system out from other logged in users should require admin privileges.

Marc Deslauriers (mdeslaur) wrote :

With a graphical login, not neccessarily.

With a graphical login on a local console (allow_active in policykit, at_console in dbus, etc.), the user should not require admin privileges.

Hanine HAMZIOUI (hanynowsky) wrote :

What about this use case

- I am logged in as an administrator
- Suddenly, my brother next to me asks to log in to check his mails for 3
minutes.
- I move to the other room while he is logged (switched to another session)
in to a Standard session (mine is still on).

When I am back, I find the machine shut down. What the heck?????
No...........

To sum it up, when multiple accounts are logged in, Ubuntu should allow
only ADMINS accounts to force the Shutdown operation or the Standard user
if he/she has the SHUTDOWN privilege. The only requirement is that a
Warning box should be displayed (Other Accounts' sessions are still open,
are you sure you want to shutdown anyway?). That's a preventive way to see
the issue from an end-user side.

-------------------------------------------------------------------------------------------------------------------------------
On Fri, Nov 30, 2012 at 6:02 PM, Marc Deslauriers <
<email address hidden>> wrote:

> With a graphical login, not neccessarily.
>
> With a graphical login on a local console (allow_active in policykit,
> at_console in dbus, etc.), the user should not require admin privileges.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (976911).
> https://bugs.launchpad.net/bugs/861171
>
> Title:
> Shutdown from greeter does nothing when multiple accounts open
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-session/+bug/861171/+subscriptions
>

Marc Deslauriers (mdeslaur) wrote :

@Hanine: What's preventing your brother from holding the power button down for 3 seconds?

Forcing admin rights to perform actions that can by bypassed with physical access would be inconsistent will all the other rights that are currently granted to console users.

Marc Deslauriers (mdeslaur) wrote :

Here's another scenario: A laptop is shared by multiple members of a household. User A is the admin, User B is not.

User B steps up to laptop with the intention of shutting it down to leave with it. User A is currently logged in.

We have two choices here:

1- Present a warning dialog to User B saying that shutting down the laptop may cause User A to lose unsaved data in open applications, but allow him to shut the laptop down anyway.

2- Present an error message saying an admin is required to shut the machine down, at which point User B simply turns the machine off with the power button, and causes disk corruption.

Marius B. Kotsbak (mariusko) wrote :

The could be locked in a cabinet so that it can't be hit by any user.

And since Ubuntu can't know, the behaviour must be configurable, and only the default must be discussed.

Marc Deslauriers (mdeslaur) wrote :

If you have access to the console keyboard, by default you can use the magic sysrq key to reboot the system.

The default should represent the most common scenario, which is physical access. If someone has locked the computer up, the magic sysrq settings, and the policykit default configuration for consolekit can be modified to fit that scenario.

Steve Langasek (vorlon) wrote :

On Fri, Nov 30, 2012 at 07:01:03PM -0000, Marc Deslauriers wrote:
> @Hanine: What's preventing your brother from holding the power button
> down for 3 seconds?

The fact that your desktop is in a locked cabinet, obviously :-)

parq (pablo-romeroquinteros) wrote :

@Kai,

You're right. We have found that both behaviors, the one you describe and the main related to this bug, have the same root: policykit

I haven't tried the patch commented by James (comment #33), but it's maybe the solution you're searching for.

Anyway, if you want to do it by hand, the workaround that I have published at comment #14 (https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/861171/comments/14) work fine and solves both behaviors!

Regards,

parq (pablo-romeroquinteros) wrote :

Thank you so much to all the people that moved this bug the last week !!!

But I think that most of you are moving in a different direction, and all of the examples in the comments could been solved by the expected behavior commented in post #20 (https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/861171/comments/20):

--- Comment #20

a. Normal user + other users logged:
"You just can't turn off the computer because there are more users logged. Please talk to an admin." [ok]
(Do nothing)

b. Admin user + other users logged:
"There are more users logged in the system. Are you sure?" [Yes/No]
(Close one by one all logged accounts and shutdown)

c. With only 1 user logged (normal or admin) don't ask and shutdown.
(Close the session and shutdown)

--- Comment #20 end

This solution prevent from abnormal session close, hardware shutdown, the actual 'only 1 normal-user logged can't shutdown', normal-user shutdown with multiple active sessions and other situations.

Then there was other improvements to this idea, in the following comments.

VERY IMPORTANT: Despite about console access and other tricky ways:

KIS,S !

Ernst Sjöstrand (ernstp) wrote :

I think a goal should be to avoid forcing users to do unclean shutdowns with the power button etc.
If I'm logged in but not at home and my wife wants to turn off the computer, she should be able to even though she's not an admin.

Robert Ancell (robert-ancell) wrote :

Here is an alternative dialog we can present. In this case you are able to continue the shutdown process if you desire and continue with the current PolicyKit behaviour. This option wouldn't be shown inside the greeter though we could fix the PolicyKit issues there and resolve that in the future.

Yann Dìnendal (yannbreliere) wrote :

Yes, but the destructive action shouldn't be the default button.

Matthew Paul Thomas (mpt) wrote :

Robert, thank you. That looks a much better design, because it provides a well-framed choice. I'd tack an "Anyway" onto the "Shut Down" button, as a hint to those who didn't read the text that something risky is about to happen.

People here have made statements of form "It's no use asking for authentication, because someone could just hold down the power button ... unless it's physically inaccessible." I don't think that logic follows. It's true that someone could just hold down the power button -- but a large percentage of people *won't* do that, because they'll realize something unexpected is going on. I suggest that security is not necessarily the only purpose of an authentication dialog, and it may not be the purpose here. Another purpose is to reduce dataloss by getting more people to pause and think about what they're about to do. And I think that more people will do that with an authentication dialog than with a vanilla confirmation dialog. The tradeoff is that an authentication dialog doesn't (with the current API, at least) allow for including a "Log Out Instead" button.

So, here is a wireframe of the single-session case, followed by wireframes of three options for the multi-session case:
A: a refinement of Robert's alternative, with "Log Out Instead", "Cancel", and "Shut Down Anyway"
B: an any-user authentication dialog, with "Cancel" and "Continue"
C: an administrator-only authentication dialog, with "Cancel" and "Continue".

Marc Deslauriers (mdeslaur) wrote :

I have no objection to an authentication dialog, as long as by default it permits a non-admin user to shut down a machine without disk corruption if he's physically present.

Alf Sagen (alfsagen) wrote :

I'd say go for your Alt A, Robert, and I agree that an authentication dialogue is better than the vanilla conf dialogue exactly like you say; This will definitely make the general "wife" or "brother" pause to think 3 seconds before shutting down & killing other sessions.

I guess that power button is accessable to the common user in about 98% of all use cases, and therefore I also agree that any user should be able to perform a proper shutdown if he/she is working locally (either from greeter or from session). HOWEVER, this makes it VERY important to keep in mind what Matthew says about really being pushy on the user...really trying to make him understand that this is serious business. (This learning also comes from Windows where quite a few of us have lost work due to the fact that wife/brother actually shut down the computer without even thinking about other users. Well...maybe not THAT many of us, since I guess Windows in general is considered a 1 user system in more cases than unix.)

In the mean time (work-around):
For anyone with slight tech knowledge (like myself, and I emphasise slight in this sentence), they are likely to have sudo permissions and be able to perform 'shutdown now' from a terminal anyway.

Thanks a lot to you guys in the team who actually FIX things for all of us others who're just whining!!

:-) alfs

Marius B. Kotsbak (mariusko) wrote :

We could add a checkbox to the dialog that needs to be checked to be able to select the destructive action, hmm, but it might be confusing for the other choices. Or maybe an extra verification dialog box with cancel as default (and maybe the checkbox here instead) that pops up when selecting the unclean shutdown.

Nick Booker (nmbooker) wrote :

I've already done the 'affects me'.

But I'd like to point out that it affects me on Xubuntu Quantal (only Precise is listed anywhere on the page at the moment).

Changed in oem-priority:
assignee: nobody → James M. Leddy (jm-leddy)
Changed in unity-greeter (Ubuntu):
assignee: nobody → Omer Akram (om26er)
Changed in indicator-session (Ubuntu):
status: Triaged → In Progress
Changed in unity-greeter (Ubuntu):
status: Triaged → Invalid
description: updated
description: updated
tags: added: rls-s-incoming
James M. Leddy (jm-leddy) wrote :

Mathieu is fixing this in saucy at the moment. We should have a fix for saucy as well as the SRU shortly. Thanks Mathieu!

Changed in unity-greeter (Ubuntu):
assignee: Omer Akram (om26er) → nobody

This bug affects me on a fresh install of raring.
The difference with what has been described so far is that if (at least) one user is logged in, and I try to shutdown from the loggin screen, it hangs forever. Can we expect to have a fix released for raring soon?

Ara Pulido (apulido) on 2013-07-01
Changed in gnome-session (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
parq (pablo-romeroquinteros) wrote :

Alt A of Matthew seems to be fine!

Ara Pulido (apulido) on 2013-07-22
Changed in oem-priority:
assignee: James M. Leddy (jm-leddy) → Ara Pulido (apulido)
Richard Hansen (a7x) on 2013-07-22
tags: added: multiseat
Alkis Georgopoulos (alkisg) wrote :

Any progress on this one?

It's very annoying on LTSP, where teachers can't shut down the LTSP servers because e.g. 2 hours ago some student had a xorg crash, and even if his thin client is now powered off, the user is still considered logged on at the server because the ssh socket isn't yet closed...

This worked fine before switching from GDM to LightDM, with the confirmation dialog etc.

Aspasia Dilalou (adilalou) wrote :

Friday, 13:50 at school. The lesson finished, the ltsp server refused to shudown and I wanted to catch the 14:00 bus to go home.
I pressed the power-off button at the back side of the system unit!

Tom Gelinas (tomgelinas) wrote :

I can't believe that this bug isn't a priority. It drives my parents nuts!
On Oct 5, 2013 7:51 AM, "Aspasia Dilalou" <email address hidden> wrote:

> Friday, 13:50 at school. The lesson finished, the ltsp server refused to
> shudown and I wanted to catch the 14:00 bus to go home.
> I pressed the power-off button at the back side of the system unit!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/861171
>
> Title:
> Shutdown from greeter does nothing when multiple accounts open
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-session/+bug/861171/+subscriptions
>

Ted Gould (ted) on 2013-10-14
Changed in indicator-session:
importance: High → Medium
Changed in indicator-session (Ubuntu):
importance: High → Medium
no longer affects: unity-greeter
Zwylicht (zwylicht) wrote :

As with 13.10 the machine will shutdown without complaining regardless which user demands it - thats also not the behaviour expected because my unsaved work will be lost. this should be allowed only to administrator or at least there should be a warning message.

tags: added: ubuntu-desktop-trusty
Changed in gnome-session (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in indicator-session (Ubuntu):
status: In Progress → Triaged
no longer affects: indicator-session (Ubuntu Precise)
no longer affects: indicator-session (Ubuntu Saucy)
no longer affects: policykit (Ubuntu Precise)
no longer affects: policykit (Ubuntu Saucy)
no longer affects: unity-greeter (Ubuntu Precise)
no longer affects: unity-greeter (Ubuntu Saucy)
no longer affects: gnome-session (Ubuntu Precise)
no longer affects: gnome-session (Ubuntu Saucy)
no longer affects: gnome-session (Ubuntu Raring)
no longer affects: indicator-session (Ubuntu Raring)
no longer affects: policykit (Ubuntu Raring)
no longer affects: unity-greeter (Ubuntu Raring)
no longer affects: unity-greeter (Ubuntu)
Changed in policykit (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Simon Steinbeiß (ochosi) wrote :

This bug doesn't affect lightdm-gtk-greeter anymore. Currently (1.8 series) users can shutdown a machine from the greeter, but the shutdown-dialog shows a warning that there are still users logged in and that there is the chance for data-loss.

Changed in lightdm-gtk-greeter:
status: Triaged → Fix Released
Ara Pulido (apulido) wrote :

Marking it as Won't Fix in OEM priority project as the behaviour in Trusty is completely different

Changed in oem-priority:
status: In Progress → Won't Fix
Robert Ancell (robert-ancell) wrote :

Closing this bug as the original problem is solved in trusty.

The default logind (the system that performs the shutdown/restart) allows an active session to perform this action. The greeter is an active session so the user can shutdown and reboot from it even when multiple sessions are open.

There are probably other issues here like:
- The greeter doesn't explicitly warn that the other sessions will be closed
- If you lock down these settings the greeter wont be able to shutdown at all
but these are better covered in new bugs if required.

affects: indicator-session → unity-greeter
no longer affects: gnome-session (Ubuntu)
no longer affects: policykit (Ubuntu)
no longer affects: indicator-session (Ubuntu)
Changed in unity-greeter:
status: Triaged → Invalid
To post a comment you must log in.