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

[Brian Cameron <Brian Cameron Sun COM>]

Simo:

>> So if your plan is to
> > make the GUI and PAM talk to each other, you could use [the Custom
>> Widgetry] interface.
> Uhmm that would mean changing pam modules just for GDM, I doubt that it
> will be easy to do.

If a PAM module needs custom information from the UI, then some
mechanism for making the GUI and PAM talk to each other would be
needed.

For example, if you need to pick domain, username, and password for
PAM to authenticate, and you wanted a custom widget to get the
domain information from the user, then you could make it work as
follows:

The PAM module could detect if the login program has the special
domain GUI plugin.  If so, then it avoids asking for domain via PAM and
instead gets the information from the GUI plugin directly.  If the GUI
doesn't support the special domain GUI plugin, then it asks for domain
over normal PAM protocols.

But for this to work, it probably requires a special PAM module that
knows how to talk to the GUI, right?

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

I only raise the issue.  Any discussion about how to improve the UI
experience needs to also take into consideration how it impacts
security.

Just because a system administrator is aware of the modules they have
installed doesn't mean that they understand the security implications.
I'm not saying this is a bad idea, just that any proposal should
include information about how security is impacted.  Some users might
want to lock down the GUI to a known set of modules that have been
reviewed for good security, for example.  Considering such things might
affect design choices.  But it probably makes more sense to wait until
someone has a prototype before we worry further about security
concerns.

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

All the SmartCard readers I have ever seen require that users enter
password via the login program rather than by entering a PIN on the card
reading device directly.  It sounds like you have a different kind of
SmartCard reader than I am familiar with.  Sorry, I didn't understand
you at first.

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

Yes, you could have a GUI module that talks directly to the device
and displays some GUI information when it knows that the device is
connected and awaiting card entry.  In my previous email I explained
how you could hide the entry field in a widget.  Adding a new canvas
item to gdmgreeter to display such status information could be
prototyped using similar mechanisms.  Or the GUI plugin could avoid
messing with the greeter GUI and instead just take over some screen
real estate for displaying its status icon/information.

> > 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.
>
> Well, unless you have callbacks that can make the SmartCard GUi plugin
> take over.

Right, you could have some code that listens for things like SmartCard
device insertion and switches tabs (restarts the PAM stack) for you
automatically.  This code could be in a GTK_MODULE or a separate daemon.

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

Remember PAM is not multi-threaded, so if GUI plugins handle PAM
conversations, then each plugin would either need to be in a separate
process or you would need some way to ensure only one plugin at a time
talks to PAM.  This sounds hard.  It probably makes sense for there
to be just one PAM stack and to restart it as needed.  Though I
notice Oswald buddenhagen seems to like the idea of multiple processes
each with their own PAM stack.  This wouldn't work with GTK_MODULES
though, since GTK_MODULES run in-process, not as separate processes.

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

Sounds reasonable to me.  Though it would be nice if someone developed
an interest in making PAM work better.  :)

Brian