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

[Simo Sorce <ssorce redhat com>]

Hi,

I would like to propose some changes to GDM knowing that a rewrite is
underway anyway. Maybe this is a good time to make some changes that can
benefit GDM users.

Please forgive me if I used some wrong terminology as I am not familiar
with the GDM specific one. Also please forgive me for the long message.

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.

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.

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.

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.


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.


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.


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.

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...

Comments are very welcome.

Simo.