Re: [gdm-list] [RFE] A modular gdm greeter

[Brian Cameron <Brian Cameron Sun COM>]

Oswald:

Thanks for the input, and you are right.  You could have multiple
plugins talking to PAM at the same time if they were all using
separate PAM stacks.

However, PAM is managed by the daemon and not the GUI, so to
support this sort of thing the daemon and the GUI would need to
be able to talk back and forth without getting any wires crossed.

In the stable GDM branch, the current technique of using stdin
and stdout is written with the assumption that there is only one
PAM stack talking at a time.  It would need some enhancements to
support multiple conversations and to differentiate which stack
is associated with a message, for example.

However, perhaps in the new D-Bus display manager, this sort of
thing would be easier to negotiate.  At any rate, it's useful to
raise this issues early so the new design can take such things
into consideration.  I think that was really the point of bringing
up this discussion, anyway.

Brian


> On Thu, Oct 04, 2007 at 03:18:54PM -0500, Brian Cameron wrote:
> > For example, if you need to pick domain, username, and password for
> > PAM to authenticate, and you wanted a custom widget to get the domain
> > information from the user, then you could make it work as follows:
> >
> > The PAM module could detect if the login program has the special
> > domain GUI plugin.  If so, then it avoids asking for domain via PAM
> > and instead gets the information from the GUI plugin directly.  If the
> > GUI doesn't support the special domain GUI plugin, then it asks for
> > domain over normal PAM protocols.
> >
> > But for this to work, it probably requires a special PAM module that
> > knows how to talk to the GUI, right?
> wrong. the ui plugin just reads the regular conversation prompts and
> processes them adequately, usually auto-answering them. if multiple
> inputs are needed and are expected to be entered in parallel, the
> plugin needs to know this in advance and would not start/continue the
> actual pam conversation until everything is available.
>
> > > The 2 stacks idea seem interesting seeing it under this PoV, it is worth
> > > thinking about it, but just letting plugins handle the PAM conversation
> > > may do as well.
> > > Smart plugins my use expect-like methods to know what to do in specific
> > > configurations.
> > Remember PAM is not multi-threaded, so if GUI plugins handle PAM
> > conversations, then each plugin would either need to be in a separate
> > process or you would need some way to ensure only one plugin at a time
> > talks to PAM.
> > This sounds hard.
> actually, it sounds wrong. :-P
> the pam stacks need to run in separate processes. however, the ui
> plugins are just widgets that are plugged into the ui and connected with
> some signals, thus nicely playing with the event loop. no need to
> multi-thread anything here. the only important thing is to make every
> plugin talk to *his* stack process. but i don't think this is a problem.