Re: [gdm-list] [RFE] A modular gdm greeter
- From: Brian Cameron <Brian Cameron Sun COM>
- To: gdm-list gnome org
- Subject: Re: [gdm-list] [RFE] A modular gdm greeter
- Date: Thu, 04 Oct 2007 16:02:41 -0500
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.
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
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.
] [Thread Prev