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

[Brian Cameron <Brian Cameron Sun COM>]

Simo:

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

Thanks for explaining.  This seems reasonable to me.  I'd even say that
it is okay to write pluggable code that only works with some PAM
configurations.  For example, the Face Browser is an example of code
that is already a part of GDM that wouldn't work (or make sense) with
some PAM configurations.

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

Oh sure, but it is what exists at the moment to do the sort of things
you seem interested in doing, so it is a useful reference point.

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

Agreed.  I don't know if anybody even uses this Custom Widgetry code.
This was implemented before I became the GDM maintainer, so I don't
know much about its history exactly.  Note that you should be able to
access the /var file even from a PAM module.  So if your plan is to
make the GUI and PAM talk to each other, you could use this interface.

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

Enhancing this code so that you could provide your own widget to
display the information with the assumption that a GTK_MODULE would
provide the widgetry would be do-able.  I'm not sure how you propose to
get the user selection to the PAM module, but I'm sure there is a
better way than using a file in /var.  :)

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

I am confused when you say this since PAM handles novel devices
currently.  So for GDM to handle interaction with PAM, it needs to be
able to work with novel devices also.

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

One drawback to using modules and shared objects is that it might be
seen as making GDM less secure.  If people can plug-in widgets into
GDM, then people might be tricked into installing a new widget that
looks great but sends your username/password information along to
some malicious user.  I only mention this because its something we
should think about.

For example, perhaps it would be a bit better if greeters were modular
in the sense that you could build your own based on a set of modules
rather than linking them at runtime.  This way, sysadmins wouldn't
have to worry about their configuration changing if someone installs
a module on their system.

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

I don't think your assertion that it "makes no sense to use a
login/password" field with SmartCards or fingerprints is always true.

Typically SmartCards are used only for username identification, and the
password is still entered.  Though you can configure PAM so that
a SmartCard acts as both username/password entry if you want.  The
common use-case for fingerprint readers is probably for it to act as
full validation, but you could configure PAM so that a fingerprint
reader works like my SmartCard example and is used to only to enter
your username.

If you don't want the username/password entry to show up at all,
then you can configure PAM to only allow authentication via SmartCard
or via Fingerprint.

But often, most users want it to work so that users can log in by either
typing in the username/password or via the SmartCard or Fingerprint
reader.  This is typically handled by making GDM accept the SmartCard or
FingerPrint entry when the user inserts the card or their finger into
the fingerprint reader.

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

If you were on a system where you knew most people would login via
SmartCard and/or Fingerprint, and you wanted to configure GDM to hide
the entry field behind a tab or button, this might make sense in some
cases.

Perhaps what you are suggesting would be to make GDM configurable so
that it would support something like tabs, where each tab is associated
with a different PAM stack.  Then when you want to use a different
authentication mechanism you just click on the tab associated with that
PAM stack.  This would allow users to easily switch between
username/password entry, SmartCard, and fingerprint PAM stacks without
the need for having secondary daemons listening and making GDM restart
the PAM stack upon receiving events (like a SmartCard insertion).  The
drawback with this approach is that you need to be on the right tab
for GDM to work.  If you were on the Username/Password entry tab and
inserted your SmartCard, for example, it wouldn't notice your SmartCard
entry until you switched to the other tab.

That might be an idea that could work well.

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

Could you give some more concrete examples?  Problems can also be caused
by poorly written PAM modules or poor PAM configuration.

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

I'd think the PAM module could access the file in /var to find the
selected domain choice.

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

If you look at your PAM configuration (refer to /etc/pam.conf or 
/etc/pam.d and look at the man pages for these interfaces).  You
will see sections like this:

login   auth requisite          pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_cred.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

This is a PAM stack that is used by programs that want to use the
"login" PAM stack.  When you authenticate all of the above PAM modules
have to give a "thumbs up" (greatly simplifying the symantics of
requisite, required, and sufficient) to authenticate the user.

Note the pam_authtok_get.so, that's the module that gets your
username/password from the entry field.

Since this is single threaded, you can't have a single PAM stack
that checks both a SmartCard device and talks to the greeter for
username/password input at the same time.

Therefore you either need to check for both in the same stack like this:

- Check SmartCard
- Check username/password entry

And then restart this stack on SmartCard insertion so the SmartCard
check is done again.

Or you need to have two stacks (one for SmartCard and one for
username/password) and restart the PAM stack with the right stack
based on which device you want to use (e.g. if you notice a Smart
Card insertion event, you want to restart with the SmartCard PAM stack).

Hopefully this explains more clearly how PAM works.  In short, some
issues you notice with the GUI may be artifacts of the uglyness
associated with how PAM itself works.  That's why I said that to
fix some UI issues, it might be necessary to enhance PAM itself.

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

I was just trying to say that you could have multiple processes with
different PAM stacks to avoid the multi-thread issues.  Then the first
one to authenticate would win.  But you would need some mechanism for
the winners to tell the losers to exit.  This is probably a ridiculous
way to try to do things, probably why you aren't following me here.

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

Yes, you could probably do something like what you want to do.  Using
gdmgreeter as an example, you could call this function to get a handle
to the entry field.

   greeter_lookup_id ("user-pw-entry")

Then call gnome_canvas_item_hide to hide that widget.  Perhaps
gdmgreeter isn't a good example to talk about since it might be going
away with the D-Bus GDM rewrite, but being able to experiment with
this sort of thing with the stable GDM might be helpful for you to
prototype things.

I'm a bit confused by when you say "when the user wants to use a
smartcard".  How would GDM know the user wants to do this?  After the
point of card insertion?  At this point, GDM and PAM should immediately
do its thing - if this is configured to be full authentication, then GDM
should disappear immediately anyway.

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

There are a lot of UI improvement opportunities in GDM and PAM, that's
true.

Brian