Re: Shutdown with gnome-session and GDM

[Jarno Gassenbauer <jarno-linux ijag de>]

On Thu, 2003-10-23 at 18:27, Mark Finlay wrote:
> You might want to take a look at
> http://bugzilla.gnome.org/show_bug.cgi?id=114432
> 
> We really need a good solution to this and
> http://bugzilla.gnome.org/show_bug.cgi?id=70710
> 

Thank you for the direct links.


> Every now and then these come up and someone has a go but we've never
> gotten it fixed. 
> 
> In the end we should have a Actions->Logout menu item that logs you out
> directly without asking for confirmation, and if the user has permission
> to shutdown, reboot or suspend there should be Actions->Shutdown,
> Actions->Reboot and Actions->Suspend respectively.

Might be possible now without much effort.

The mechanism of the solution is:
* the logout dialog queries GDM which logout actions (plain logout,
  halt, reboot, or suspend) are supported and which one currently is
  set as default.
* GDM checked for binaries for shutdown, reboot and suspend at startup
  and now reports the results.
* The logout dialog pre-activates the radio button corresponding to
  GDM's current default action and makes all radio buttons insensitive
  that were reported to be unsupported.
* the user plays with the dialog.
* the logout dialog tells GDM which logout action the user requested.
* The user clicks OK or Cancel. If he clicks OK:

* gnome-session saves states and exits.
* GDM runs the Post-Session scripts. Currently they just remove the user
  from utmp/wtmp, I think.
* GDM shuts down the X server that belonged to gnome-session
* If the (new) default logout action is "plain logout" GDM starts a
  new X server and presents a login prompt as usual.
* Otherwise the (new) default logout action gets executed.

=>  No flicker, clean run of GDM's Post Session scripts.


Now regarding security:
For now, before the GDM's setting of the default logout action can
be changed, the user must authenticate with GDM using his MIT magic
cookie.
Only cookies that belong to a local X session can authenticate,
that is if communication to the X server is done through a unix domain
socket instead of a TCP connection (the GDM maintainer can explain this
much better/more correct).
The bad implication is that any local process would be able to reboot
the machine as soon as he gets access to a user's .Xauthority file or
to the cookie within.


About the panel menu entries:
Don't know how the entries in the panel's action menu work, but if they
1) can execute a binary to communicate the logout action to GDM and
2) can make gnome-session exit (or make it crash - that works as well)
then they can perform any of the new logout actions. If the menu entries
can run some C code, they can talk to GDM themselves instead of calling
an executable.


Before applying the gnome-session patch, be warned that it is currently
using non-blocking IO and therefore is rather complex!!!

After the logout dialog appears, the radio buttons are set insensitive
until GDM reports some/all to be made available to the user. The patch
also updates the default action in GDM as soon as a radio button in
the logout dialog is clicked. The recently clicked button is being set
insensitive until GDM returns a success notification; and left
insensitive in case a failure notification is returned by GDM.

The next current feature that requires discussion first is the fact
that the default logout action is NOT restored to its old value as
soon as the Cancel button is being clicked. My intention was to
set the default action in the logout dialog, be able to return to GNOME
and have that action executed when you press Ctrl-Alt-Delete or when
gnome-session crashes. This setting will be shown to the user the next
time he opens the logout dialog (the corresponding radio button will be
pre-selected). Others already pointed out that this is not intuitive
and therefore would be non-HIG. (What about an apply button?)

Generally, the code for gnome-session or the panel menues can be made
MUCH simpler by using blocking IO in the logout dialog, as strongly
promoted by the GDM maintainer.
And, this wouldn't confuse the user with radio buttons becoming
sensitive and insensitive all day long. The user's choice would be
communicated to GDM only after clicking OK.

Greetings,
Jarno