Re: [gdm-list] [PATCH] some pam related improvements

[Brian Cameron <Brian Cameron Sun COM>]

Ludwig:

> > > ------------------------------------------------------------------------
> > >
> > > - don't make the start again button insensitive as the prompt for
> > >   the username is not necessarily the first.
> > Why change the calls to set_sensitive to always be TRUE, why not just
> > rip out all calls to set the sensitivity for this button?
>
> The buttons are still set to insensitive if there is nothing to do
> for the GUI, e.g. when the backend sleeps due to a failed
> authentication.

That's a good point.

> > Also, might there be a better solution.  We want the "Start Again"
> > button to be active at all times except when the GUI is prompting for
> > the first item.  Perhaps trying to set button sensitivity in the
> > current GDM_PROMPT, GDM_NOECHO locations isn't the right place.  So I
> > ask if the right fix is to rip out setting sensitivity or to move it so
> > it is setting it more intelligently?
>
> How do you know it's the first item? There can be multiple pam
> conversations that belong to one authentication run.

So you are saying that the GUI has no way of knowing which is the
first item?  I'd think the first item would be the first screen
or the first screen after any authentication failure.

If it is not possible to identify the first screen, then I am agreeable
to making the button always sensitive and accepting your previously
proposed patch.  I wanted to discuss it a bit first to see if there is
a way to make it work without just making it always sensitive.

> Anyways, with
> multiple pam prompts the button is also useful on the first screen
> to clear all entries.

Right, but "Start Again" could remain insensitive until at least on
field has a value.

Speaking of this, does the "OK" button need to be updated so that
it remains insensitive until all fields have something entered?
It probably doesn't work this way right now.

> > I think this change also needs to be made to gdmgreeter.
>
> I haven't looked too closely into gdmgreeter yet.

Since I am making the changes you suggest to SVN head and we are
close to releasing GNOME 2.18, I would appreciate if you could
verify that gdmgreeter is working reasonably.  Now that we're in
beta I'd hate to release a version of GDM where gdmlogin works but
gdmgreeter does not.

> > > - don't tell backend that a user was selected in the face browser if
> > >   the backend itself caused that to avoid aborting an ongoing
> > >   authentication.
> > I assume this is no longer needed because we are now managing this
> > in verify-pam.c?  Is this correct?  But what about if GDM is using
> > verify-crypt.c or verify-shadow.c, don't we also need some similar
> > sort of hack to make this work the same for crypt/shadow?
>
> I don't know, someone would need to test it. I wonder whether it
> would make sense to emulate the PAM api for those two authentication
> methods instead of duplicating lots of gdm logic.

Yes, this would be really nice and clean up a lot of cruft, I think.
I never liked the way the code is duplicated in these three files.
Also making the other two modes simulate PAM would probably make
the "user in the face browser remains selected for 3 tries" feature
work more consistently for all 3 modes.

Note when you run configure you can pass in
--enable-authentication-scheme=[pam/crypt/shadow] to specify which
method to use.  If you can, I would appreciate if you (at the very
least) tested to make sure that your modifications (especially the
changes to GUI behavior) aren't causing any serious issues for the
other schemes.

Breaking of the aforementioned "face browser user remains selected
for 3 tries" in the other modes isn't a huge deal if its the only
thing that is different with the crypt/shadow schemes.

Brian