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

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

Hi Simo,

On 10/3/07, Simo Sorce <ssorce redhat com> wrote:
...
> Currently the GDM interface seem to be quite rigid in the way it present
> information needed to login the users. It would be nice if GDM could
> support a plugin system so that enhancements to the UI can be easily
> added depending on the environment it is used in, without requiring core
> changes to GDM itself.
> This would make it more robust as developers can concentrate on the
> core, and would let other devs with specific needs customize it as they
> need.

This makes a lot of sense to me.  It is really unavoidable given the
nature of open source.  The first level of modularity is already in
place: the greeter itself will have a fairly well defined interface to
the daemon and can simply be replaced.  The next level is, as you
suggest, having pluggable individual components.  And there are a few
reasons for that...

> The use cases I see are a few:
> Face/Avatar browser
> Windows Domains chooser
> Kerberos Realms chooser
> Smartcards
> Fingerprint readers
> OTP Passwords
> Etc...
>
> In the past there have been some patches to introduce a selector to show
> windows domains for example, and currently some distros show a face
> browser.
> Someone suggested that PAM should handle domains lists or other
> "prompts", but the problem is that the PAM interface is strictly
> serialized because it needs to be usable for text only logins and does
> not suite well the needs of a GUI. The worst case is when you have
> multiple PAM module and each of them need to show something to the user
> before the user logs in.

Very much in agreement.
"Username or insert card or scan iris or swipe finger:"

> A puggable system would make it possible to let people plug-in GUI
> enhancements but keep GDM doing any PAM conversation once the GUI plugin
> has set up the environment and received enough input to send to PAM
> (without necessarily prompting the user, see use cases).
>
> I hope we can have a discussion around this idea.
>
> You can skip the following paragraphs to Conclusions if you like :-)
>
> What follows are a few use case examples that I hope can explain why a
> modular system would be useful.
>
> Face/Avatar browser:
> A pluggable system would let you choose whether to actually show a list
> of users, how to filter it and how to populate it. There are many
> methods to present such list and it is easier to swap in a different
> plugin then trying to provide all possible ways by means of
> configuration options.

Perhaps.  It isn't a panacea.  It can make it more difficult to create
a well integrated experience - or perform animation etc.  Anyway...

> For example, right now the Face browser Fedora uses just try to list all
> users, it filters out accounts with UID < 500 and cut the list based on
> timeout/number of users. While this is somewhat ok for the single
> desktop system with a few users, it becomes quickly silly as soon as you
> have thousands of users coming in via LDAP, NIS, Winbindd etc..
> Another way to implement a sensible face browser is to just "remember"
> previous logins and just show "known" users. This is useful for example
> with Winbindd which by default do not allow enumerations and therefore
> always present a blank set of users in the face browser. It also reduces
> the load on LDAP/NIS servers as enumeration is always an expensive
> operation.
> It also address offline cases (a laptop), which at the moment are
> supported by winbindd and where enumeration beyond cached users is
> anyway impossible.

Completely agree.  This is exactly what I hope to do with the user
chooser.  I think we should always display this chooser.  The other
question is when should we also display a username field?  In general,
whenever we have any non-local directory - but how do we detect that
other than by timeout/number of users?

> Windows Domains/Kerberos Realms:
>
> In some setups, people is connected (via trusts) to several
> domains/kerberos Realms and can login into different ones.
> In these environments face browsers are less interesting (and avatar
> browsers even less as usually the home directory of the user is not
> available until login is performed) while having a list of domains from
> which to choose is really useful for users.
> A plugin could provide a domain browser that would be able to compose
> the right username combining the login name and the domain/realm chosen
> to pass to PAM to start pam authentication. Many users are already
> familiar with these scheme.
>
> Mixing a "remembering" face browser with a domain selector would also
> probably be a useful scenario.

Yeah, the user chooser is still useful here, I think.  But yeah, the
domain chooser is a good example of something that most people won't
want to see.  How do we detect that it should be displayed?

>
> Smartcard/Fingerprint readder:
>
> These kind of devices have a different way to interact with users then a
> normal username/password prompt. Ideally a user should be allowed to
> just swipe the finger/insert a smartcard without being requested neither
> a username, nor a password, but still you want to make them interact
> with pam so that all access limits and other useful pam modules are
> correctly invoked.
> Again a plugin could change the UI to show a smart card or a finger
> print reader and once the smart card is inserted or the finger swiped
> they could build a username to be passed to pam to start the
> conversation and later pass in whatever token the corresponding pam
> module expects to finalize authentication.

This is an interesting case for a number of reasons.  As you say, it
still needs to go through PAM - and in some cases the authentication
is two factor.  But PAM isn't sufficient.  We need something to
interrupt and restart the PAM stack.  And we certainly shouldn't be
doing anything if this particular seat doesn't have the necessary
hardware.

> Conclusions:
>
> Trying to address all these scenarios with a generic module or trying to
> do it using only PAM conversations would probably result in a poor UI
> experience like it is now. Also, as PAM is serialized, combination of
> the above would be really nasty as a user may end up being require to
> fail an authentication method on purpose just to be asked for the right
> stuff.
>
> As an example a desktop set-up to use smartcards for some logins but
> still allowing windows domain logons for legacy windows domains. In this
> situation a plugin system could allow the GDM greeter to show both a
> smartcard sign and a domain list chooser, it can be done by a tabbed
> greeter or something else (with persistence, ie the next time the
> default tab is set to be the last used), the modular system should allow
> you to handle that and also nest multiple plugins when necessary. Once a
> plugin starts getting input it becomes the dominant one and try to
> perform an authentication, all others become disabled until either login
> succeeds or fails.

Can you give an example of how this might work?  The other examples
you give are mostly about setting up the initial conditions rather
than handling PAM conversations.

> The end result is that this would make GDM a lot more customizable for
> the specific needs of the specific environment it is used in, without
> trying to address all possible scenarios at once. It would also allow
> future authentication schemes not known today without changing the core
> functionality of GDM.
>
> It may also be a way to avoid polluting the configuration file, as
> plugins can use their own, and all GDM would be required to do is to
> provide a way to specify which plugins the admin want to show up.
> Plugins on their own may then decide to show up and actually register if
> they can successfully init. A lazy admin may add all available plugins,
> but plugins that can't initialize wouldn't show up.
> If the smartcard reader plugin finds out no smart card reader is present
> it would just disable itself, same for a winbindd plugin that finds out
> winbindd is not set up, or for a fingerprint plugin that does not find a
> fingerprint reader, etc...

Certainly.  But how do you propose to marshal the PAM messages to the
respective plugins?  Just sending them to one plugin regardless of
what PAM module sent them doesn't seem right either...

But anyway, these are good ideas.  Thanks for starting the discussion!

Jon

Jon