Re: [gdm-list] GObject branch

["William Jon McCann" <mccann jhu edu>]

Hey,

On 6/5/07, William Jon McCann <mccann jhu edu> wrote:
> On 6/4/07, Ray Strode <halfline gmail com> wrote:
...
> > I tried to make some progress on that front some time ago here:
> >
> > http://people.redhat.com/rstrode/session.h
> > http://people.redhat.com/rstrode/session.c
>
> Agree.  And this looks great already!  Made a few minor changes
> (mostly for style consistency) and committed to the branch.  Separated
> out the test program.  Thanks Ray - this saves a lot of time and
> effort.
>
> > But I never finished, and since d-bus is a requirement of gdm now, it
> > makes a lot of sense to use dbus instead of the ugly, socket protocol
> > I came up with at the time.
>
> Yeah, perhaps.  Not too worried about that yet since it is an internal
> detail.  Also, last I tried D-Bus didn't like having connections open
> in both parent and child of a fork without exec.  Next thing to do is
> just make the greeter talk to this object over D-Bus...

Ok, so this is now done in the branch.  I've connected the slave to
the greeter using a peer to peer D-Bus connection.

The way it works for now,  the slave side creates a DBusServer and
passes the address to the greeter child via the environment.  The
greeter (child) makes a peer to peer connection to the Slave, listens
to signals, and then calls into the GdmGreeter object to do stuff.
Then when the GdmGreeter has an answer or a session/language selection
the greeter child calls back into the Slave.

This should make it easier to write decent greeters too since it is
now reduced to:
http://svn.gnome.org/viewcvs/gdm2/branches/mccann-gobject/gui/greeter/greeter.c?revision=4980&view=markup

Where GdmGreeter is an abstract class:
http://svn.gnome.org/viewcvs/gdm2/branches/mccann-gobject/gui/gdm-greeter.h?revision=4980&view=markup

For the first time the branch can actually start a session!  Both
"static" and XDMCP logins seem to work.  So, please give the branch a
try.


One thing that we may want to consider is having a session-factory
type greeter display.  What I mean by this is a greeter that always
runs on a particular X server and opens session on new X servers.
Obviously, this will only work where VT switching is possible.

Some quick thoughts on how we might be able to do this:
Create a new GdmStaticGreeterDisplay subclass of GdmDisplay.  In which
a slave would respond to each greeter start by communicating back to
the Master to create a new GdmSingleSessionDisplay.  This kind of
display would not display a greeter but would create a slave that
establishes a DBusServer for its GdmSession object.  The StaticGreeter
could then communicate directly with this Session object.  If the
greeter cancels or times out the other Display is reset.  Or, if the
session can authenticate the user, a session is started.  When the new
session is ready the VT is switched to the new session and the greeter
is reset and the process repeated.

There are a few nice things about this approach.

* Fixes http://bugzilla.gnome.org/show_bug.cgi?id=343539
* For security it is better to have a well known, trustworthy location
from which to request passwords and stuff.
* Makes gdmflexiserver trivial (just VT switch to greeter location)
* Can use GDM greeter instead of screensaver
* Easier to make greeter a smart session (with gnome-power-manager etc)
* May provide a better user experience

Thoughts?

Jon