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

[Simo Sorce <ssorce redhat com>]

On Wed, 2007-10-03 at 10:33 -0500, Brian Cameron wrote:
> 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.

Good.

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

Perhaps I should have made it clear I don't want, in any way, replace or
walk around PAM with this proposal. As pointed into the mail, the PAM
stack need absolutely to be called (there are many modules that need to
be used besides the actual one that checks the credentials), I am just
suggesting to make it possible to change the GDM interface through
plugins so that a more appropriate GUI is used depending on which login
method you like to use. The idea is that all will work as it currently
does in case you have no other plugin and show the default greeter with
the usual login and password fields. It will just be uglier, but as it
uses PAM it will work the same.

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

Yes this is the intent, providing a better interface to users.

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

I think you can agree with me that this is a very limited interface.

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

Yes it may indeed be useful but it is also very limited and does not
help enhancing the UI in many cases.

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

This is all very fragile indeed, and also can't address very well the scenarios I presented.

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

The list is dynamic of course. True, running a script to generate it is
possible, but I am not much interested in how to retrieve it right now,
but in how you present this information to users.

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

Yes, this is the problem, I think GDM core should concentrate more on
the fine mechanisms of how to handle sessions and the interaction with
PAM rather than how to handle the greeter UI besides the classic
user/password prompt.

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

Sure but trying to fit all this into the core code would require changes
to always be included into the main code, support for loadable plugins
that come in form of a .so libraries would probably make the core more
stable and give more freedom to experiment. The best UI plugins can then
be incorporated back upstream for general distribution.

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

Sure, some are implementation deficiencies, but the face browser was
just an example.

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

I am not advocating skipping PAM, what I am advocating is to have a way
to present a better UI. For example with smartcards or fingerprints it
make no sense to use a login/password field. The smartcard or your
fingerprint contains all the information needed to carry on the PAM
conversation.
The idea is that a plugin could be written that does not show by default
the login/password prompt [but a tab with the default login/password
prompt will be present so that a user can choose to use it].
This plugin would just show a smart card graphic and will catch a signal
from the smartcard daemon that a smartcard have been inserted. At that
point a normal pam conversation will be started and normal login will be
performed.

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

Sure, infact it is done, but the UI is really poor and show stuff that
does not make much sense in the specific case as it has to be generic.

>   Such solutions
> may require a daemon listening for USB/SmartCard input and restarting
> the PAM stack as needed (by restarting the greeter, for example).

Yes, see above.

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

Because the greeter needs to combine the domain and the username into a
single string and use that as the username for PAM, I don't think this
is possible right now.

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

I think you mis-understood my proposal, as I said I am not interested in
replacing PAM, just in making it possible to provide a better UI without
changing the main GDM code.

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

I was talking about multiple pam modules, not multiple stacks, I am not
sure what purpose using multiple stacks would serve.

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

Uhmm I don't think I follow you here.

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

If they want a better UI it could be a good idea to support the same
plugins or similar ones, but as this is just cosmetic work, anything
that uses PAM will just work.

> The point of PAM is to avoid
> needing to edit every program that asks for a password when a new
> authentication mechanism is created.

Right, but that does not mean you can't make these programs work better
if you know of new auth mechanisms. A better UI helps, but is not
mandatory, as I said, the idea is the even with the default UI which
will be basically what we have right now, all will just works as it does
now.

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

Sure, that's true, but then interaction between separate programs and
GDM becomes a problem.

> What beyond the normal GTK_MODULE
> interfaces do you feel you would need to do what you suggest?

Uhmm can GTK_MODULE actually change the GDM UI? For example to conceal
the login: prompt when the user want to use a smartcard ?

> Maybe
> if you proposed exactly what interface changes you think are needed,
> it would help me to understand what you are proposing?

In the end I think that being able to replace/change the greeter in a
pluggable way is what is needed.

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

Perhaps PAM could be enhanced to better suite these needs, but GDM can
do a lot to make a better UI even with the current PAM interface IMO.

Simo.