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

[Simo Sorce <ssorce redhat com>]

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

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

Uhmm that would mean changing pam modules just for GDM, I doubt that it
will be easy to do.

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

I guess so :)

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

Well I am not concerned about novel devices in this case, but about
providing a good interface for users on known devices, so that the right
graphics can be shown. 

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

Uhmm I don't think I buy it, if you can trick a user to install a new
module (which means actually installing a new package on most
platforms), I can guess you can trick him to update the gdm package
altogether.

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

Who can install a module on a system if not the admin ?
This is all stuff that needs to be done by the superuser anyway, I am
not sure I see how an admin can install a module and not know about it.

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

True, most smartcard requires a pin to unlock the device and actually
allow it to perform authentication. But there are devices that has a
keypad and do not require you to insert the PIN in any GDM prompt. In
this case it would be nice if the plugin could catch the request to
insert the pin in the hw keypad by showing some graphics instead of just
a text message. Sure this means tight coupling with the specific pam
module and hardware, but this is why I'd like a modular plugin system so
that this kind of integration can be done.

> Typically SmartCards are used only for username identification, and the
> password is still entered.

No, actually that's just a PIN to unlock the signing engine in the
smartcard.

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

You could do that, but I'd like to be able to set up a personalized
system so that the best method "can" be used, while normal installations
will just use the default greeter and show the usual PAM messages.

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

Yes, but see above.

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

This is the case.

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

I am not sure I necessarily want to use multiple stacks.
Some configurations can work with a single stack where multiple pam
modules marked as "sufficient" would work. This of course means that the
plugin will need to handle "extra" messages in a meaningful way.

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

This way seem anyway interesting, I will think some more what implies
having multiple stacks. It could actually make managing pam conf files
just easier, need to think about that.

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

Well, unless you have callbacks that can make the SmartCard GUi plugin
take over.
I think this can be done with a single PAM stack if done sensibly.
Most plugins except the default one may work only with some specific
configurations of the PAM stack, but I think that is acceptable.

> That might be an idea that could work well.

It might indeed.

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

Sure, what I mean is that right now, all you can show are text messages
and input boxes (mostly), I'd like for modules to be able to be a little
more interactive and perhaps show graphics to help the user understand
what is requested.

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

See above, changing the pam module may be difficult.

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

No but you can have 2 pam module with the first being "sufficient" and
the second "required" in the same stack. If the plugin uses wisely the
PAM conversation it can understand what to do.

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

The 2 stacks idea seem interesting seeing it under this PoV, it is worth
thinking about it, but just letting plugins handle the PAM conversation
may do as well.
Smart plugins my use expect-like methods to know what to do in specific
configurations.

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

I know, (un)fortunately I know very well how PAM works, and I know part
of the UI limitations are due to PAM limitations. I just happen to think
that we can try to overcome some of the PAM limitations in a DM while we
wait for the PAM people to catch up with GUIs needs :-)

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

Ah, yes now I see.

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

I meant before, the card insertion, it would be nice to have
customizable graphics to help the user understand a smartcard login is
requested.

I am thinking of the case where normal user/pass login is possible at
the same time (almost always if root is allowed to login), so that while
GDM shows a Username prompt, the "SmartCard gDM plugin will also show
some graphics that tell the user a smart card can be used, but only if
the smartcard device is actually present.

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

Yes, and I am trying to start from the tool that needs to set the
requirements, starting from PAM wouldn't make sense :-)
I believe that if we can make it easier to write custom plugins it will
also be easier to show what are the deficiencies of PAM and hopefully
push for it to be changed.

Simo.