Re: [gdm-list] GObject branch

["Ray Strode" <halfline gmail com>]

Hi,

> Just a quick update on the status of the GObject branch [1] [2].
>
> * D-Bus is now required
> * The class design should be pretty much set.  It seems to work fairly well.
> * The slave process management seems to work well.
> * There is another reworking of the configuration framework.  It still
> uses the same desktop file backend.  It is mostly done except for the
> change notification stuff.  The new system works a bit like GConf
> except the backend only knows strings - all typing and interpretation
> of schemas occurs in the client.
> * Simplified the XDMCP management even more by abstracting all address
> details (GdmAddress).
> * Reworked the md5 and cookie code.
> * Added a new generic posix signal handling singleton.
> * The SUP and SOP socket protocols have been removed in favor of the
> separate configuration framework and the D-Bus object API.
> * At least for now I've removed gdmsetup/gdmlogin/gdmphotosetup/gdmdynamic
> * I don't think I'm going to continue to read the server
> configurations from the configuration file but rather talk to HAL or
> PolicyKit to determine what seats are available.  We should
> dynamically create a display/greeter per seat.  XDMCP works as before.
Awesome work Jon!

> Ray, I'd like to hear your thoughts on how to redesign the greeter
> control and verify subsystems in light of your smartcard/threaded
> work.
Well, boc, recently picked up the smart card stuff and moved it to a
dbus daemon that emits signals for insertion and removal of tokens.

I think the gdm integration should basically be:

1) Listen for Inserted or Removed dbus signal and reset pam conversation.

That's it.  the pam stack should do the rest.

Now, having said that...  PAM modules can get pretty dirty.  They do
bad things to the running process, crash, block indefinitely, mess
with the environment, etc, so I think every pam conversation should
always be run in its own process, independent of anything else.  There
is just too much that can go wrong otherwise.

One complication is that the login session must be run from the
process that pam ran in, because it sets up the environment for the
session.  So we need to fork() early before starting the pam
conversation, die in the child if the conversation fails, or exec the
session if the conversation succeeds.  Anything unrelated to starting
a login session should happen inside the parent process.

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

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.

> Still kinda in pieces but coming together.  Let me know what you think.
I haven't looked super closely yet, but will try to soon.

--Ray