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

[Brian Cameron <Brian Cameron Sun COM>]

Simo:

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

Indeed, a good time to bring up suggestions.

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

No worries.

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

True, but you need to be careful.  The point of supporting PAM is to
avoid having to customize all programs that do authentication.  It is
a bad idea to customize GDM in a way that would also require
customization in the screen lock program, command line authentication
tools, etc.

However, to provide features like the Face Browser, or to allow the
user to pick options that might affect how the session is started
and stopped (e.g. by affecting the PreSession/PostSession script),
makes more sense.

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

It is true that GDM could support more sophisticated "pluggable" user
interface features.  At the moment, gdmgreeter does support some custom
widgetry which you should check out:

http://www.gnome.org/projects/gdm/docs/2.20/thememanual.html#customwidgetry

This allows you to provide the user with an extra list or combo box
style of entry, and the information about the choice selection is saved
in a file named /var/lib/gdm/$DISPLAY.GreeterInfo

This is useful, for example, if you want to pass information along to
the PreSession/PostSession script to affect how it starts up your
session.

This "custom widgetry" is somewhat limited in a few ways that could
probably be fixed if someone wanted to dedicate some attention to this
area of the code.  For example, it only supports a hardcoded list of
choices that must be in the theme, and doesn't support dynamic choices.

Also, the /var/lib/gdm/$DISPLAY.GreeterInfo interface seems a bit
fragile.  It probably breaks if a user logs onto the same display a
second time via Xnest, for example.  It might be nicer to make a better
interface to support this sort of "custom widgetry".

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

If the list of domains is a static list, you could use the existing
custom widgetry feature to manage this.  If the list is dynamic,
extending the interface to allow you to run a script to generate the
list probably wouldn't be that hard.

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

Yes, it would be nice to support the ability to let people plug in their
own face browsers.  This would require enhancing the Face Browser code
so that the interfaces are exposed so people can add their own code
if they want.  At the moment, the Face Browser is hardcoded into the
GUI greeter code directly.

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

These are just bugs in the current implementation.  Would be nice if
someone wanted to fix this code to work better in environments with
thousands of users.  Would also be possible to add further configuration
options to allow you to filter the users.

> Another way to implement a sensible face browser is to just "remember"
> previous logins and just show "known" users.

GDM already supports Include and Exclude configuration options so that
you can specify which users show up in the face browser.  It could
probably be further enhanced to support wildcards and such.  An
enhancement so that it remembers users also seems reasonable, though
such a feature should be configurable so you could turn it on or off.

> 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 sort of thing should be implemented only in PAM and it probably
does not make sense to try and enhance the login GUI to support such
novel devices.  PAM is already designed to work with novel devices.

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

It is possible to use GDM and PAM as-is to support both smartcard and
user-password entry, so the user can do either-or.  Such solutions
may require a daemon listening for USB/SmartCard input and restarting
the PAM stack as needed (by restarting the greeter, for example).

If you want to query the user for domains, why doesn't the existing
"custom widgetry" meet your needs?

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

You may be trying to reinvent the wheel here.  PAM should already
allow people to use novel and multiple authentication mechanisms if
properly configured.

Note that PAM is not multi-thread safe, so if you really want to
support multiple PAM stacks at the same time, you would need multiple
processes.

These multiple processes would probably need to talk to each other so
that when one authenticated, then it would probably need to tell the
other processes to stop.  This sounds like it could get complicated.

Then what do you do for other programs that require authentication,
such as the screensaver?  Do these programs also need to be enhanced
to work with a similar module approach?  The point of PAM is to avoid
needing to edit every program that asks for a password when a new
authentication mechanism is created.

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

There is nothing stopping you from using a GTK_MODULE or launching
additional programs at login time to do additional things if you think
this is something you want to do.  What beyond the normal GTK_MODULE
interfaces do you feel you would need to do what you suggest?  Maybe
if you proposed exactly what interface changes you think are needed,
it would help me to understand what you are proposing?

Or perhaps PAM itself should be enhanced to better support doing new
things that people want to do.  Such as supporting multi-threading
style solutions.

Brian