If there are multiple sessions logged in, you need polkit authorization to shut down now. It used to just check for more than one session, but now it checks if it's the same user logged in:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=409133be63387fc04d927e8aecd2f6ba03d2f143

So you need the latest systemd here.

this was with systemd 191

but, regardless of systemd version, I just don't think we ever want to see a polkit dialog on the login screen. We should not provide a polkit agent in this mode, basically.

What should we do if there are other users inhibiting shutdown, then?

http://git.gnome.org/browse/gnome-shell/commit/js/ui/sessionMode.js?id=0725a7d836d658a54ddb53ab1d106c6422b8a280

(In reply to comment #3)
> What should we do if there are other users inhibiting shutdown, then?

Say "I'm sorry Dave" ?

Simply removing the 'polkitAgent' from the components for login and lock screen modes fixes the issue of polkit dialogs popping up.

It would be nice if we could detect the situation where a polkit challenge would come up, and make the menuitems insensitive.

So, to answer a long-standing question:

(In reply to comment #0)
> I don't think we ever want to see a polkit dialog there, or do we ?

We do. That's the whole point of the new feature.

Could we please get the designers input on this?

What new feature are you talking about ? 

The point of having some status on the login screen was certainly not to show polkit dialogs there.

(In reply to comment #8)
> What new feature are you talking about ? 

The systemd sessions stuff where it explicitly uses polkit when wanting to shut down with multiple users.

yes, we want polkit policy to govern shutdown with multiple users
no, we do not want polkit dialogs on the login or lock screens, ever

so what should happen if there are multiple users logged in, someone goes switch-user and then chooses power off from the power menu?

I would say the menuitem should be disabled on the login screen if it would trigger a policykit dialog. Alternatively, you could pop a notification saying that powering off is not allowed because multiple users are logged in.

To me those two choices don't seem optimal.  in the first case, the user may wonder why it gets disabled some times. In the second case, it's really a pretty cruddy experience for the user to get offered something, and then why take us up on the offer get told "haha, just kidding".

On the other hand, showing a password dialog isn't optimal either since we don't know which administrator to ask the password for.

Not sure what the right answer is.

To be honest, I think we should just allow the user to quit without any prompts if they're at a local seat, where drago01's "he can just pull the battery/plug" reasoning makes more sense.

(In reply to comment #2)
> this was with systemd 191

Wait, that should have the new hooks, then. We shouldn't show the prompt in this case. This is effectively a systemd bug.

(In reply to comment #14)
> To be honest, I think we should just allow the user to quit without any prompts
> if they're at a local seat, where drago01's "he can just pull the battery/plug"
> reasoning makes more sense.

hey, i mid-air collided with you saying basically the same thing.  We should just change the policy to not require authentication in that case.

What is 'that case' ?

I don't want people to be able to just walk up to my locked laptop, switch to the login screen, and shut it down, killing my locked session.

And yes, they can pull the cable, I know. They can also smash the screen.

guess i don't see a big difference between goes to the menu item to shutdown and "presses the power button for 10 seconds to force it off" from a security point of view.

Anyway, what's your preference going forward? desensitize the menu item if multiple users are logged in?

(In reply to comment #18)
> guess i don't see a big difference between goes to the menu item to shutdown
> and "presses the power button for 10 seconds to force it off" from a security
> point of view.

Right, there's no security benefit in the sense of stopping malicious people to kill another user's session. However there's still the case of "preventing" users that are simply unaware of other open sessions to kill those accidentally - some kind of "Other users are currently logged in on this computer and may loose their work if you power off now.   <Cancel>   <Power Off>" confirmation would appear the most natural to me if system modal dialogs on the unlock/login screen weren't that odd ...

hmm that's an interesting idea,

1) add an inhibitor to the login screen gnome-session for every session that's logged in,

2) if the user clicks on the inhibitor list it user switches to that users session.  Of course they'll need to type in the user's password at that point so the whole experience could seem a little awkward if not done right.

<Cancel>   <Power Off>

At most it should say "Try anyway" - the policy may not allow it.

It would be nice to figure that out beforehand, though a dialog like this would still be almost as icky as a polkit one, so I'm not actually suggesting that anyway :-)

Created attachment 228675 [details] [review]
remove polkit agent

Created attachment 228676 [details] [review]
hide reboot and poweroff when they don't work

Review of attachment 228676 [details] [review]:

This makes no sense .. not being able to shutdown the system just because someone is logged in would just tempt users to hard power off the system. (There should not even be a password prompt when this happens in the session).

I'd even go as far and say that the current state (even though it sucks) is less broken as with this patches.

(In reply to comment #25)
> Review of attachment 228676 [details] [review]:
> 
> This makes no sense .. not being able to shutdown the system just because
> someone is logged in would just tempt users to hard power off the system.
> (There should not even be a password prompt when this happens in the session).
> 
> I'd even go as far and say that the current state (even though it sucks) is
> less broken as with this patches.

If you don't think it makes sense to prevent shutdown 'just because someone is logged in', then you change your polkit policy to allow anybody to to shutdown your system at any time. Problem solved...

(In reply to comment #26)
> (In reply to comment #25)
> > Review of attachment 228676 [details] [review] [details]:
> > 
> > This makes no sense .. not being able to shutdown the system just because
> > someone is logged in would just tempt users to hard power off the system.
> > (There should not even be a password prompt when this happens in the session).
> > 
> > I'd even go as far and say that the current state (even though it sucks) is
> > less broken as with this patches.
> 
> If you don't think it makes sense to prevent shutdown 'just because someone is
> logged in', then you change your polkit policy to allow anybody to to shutdown
> your system at any time. Problem solved...

No. We should do this by default. We should warn the user "someone else is logged in are you sure you want to shutdown?" and then just do it. We should never ask for a password (for non remote users) and we should never hide the shutdown entry with no indication to the user at all why this is the case. "Huh? I cannot shutdown something is broken lets hard power off the system then".

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.