Re: [gdm-list] how to use authentication feature of GDM in a screen saver

[Ray Strode <halfline gmail com>]

Hi,

On Thu, Apr 8, 2010 at 5:33 PM, Oswald Buddenhagen <ossi kde org> wrote:
> On Thu, Apr 08, 2010 at 04:12:27PM -0400, Ray Strode wrote:
>> This same worker already has some stub code for doing
>> reauthentication.  It might make sense to flesh that stub code out
>> rather than starting a new worker and getting a fresh pam handle.
>> This may cause issues in practice.  I haven't tried it.
>>
> it is indeed very likely that it will cause issues. the pam_krb5 module
> has done nasty things in the past when i tried to REFRESH_CRED from a
> setuid root unlocker (hmm, i still haven't tested what would happen if i
> reset the real uid to root as well). but then, you may have the
> resources to verify all modules and fix the broken ones. it is
> definitely The Right Thing To Do (TM) imo.

Well this is a little different than having a fresh root process
refresh credentials.  This would be having the same process that
opened the session, reuse its pam handle to do reauthentication. It's
sitting their running anyway so that i can call close_session after
the session exits.  Since it's the same process that initially
established credentials with pam_setcred, I think it should work for
reestablishing credentials.  But you're right, i have no idea if it
will work in practice.

> a "sticky" factory server might be a tad expensive resource-wise.
> i'd fire up a new server only when a new session is requested or when
> any session gets locked.
> otoh, starting up a new x server and greeter for any type of
> locking/switching may make that function anything but fast (though you
> are less likely to have that problem than me with kdm).
It's a trade off I guess. I think it's probably okay to start early.
I mean, if it was so expensive it mattered, then fast user switching
wouldn't be practical.

> in any case i see two fundamental problems:
> - there *may* be pam modules which can't deal with PAM_XDISPLAY not
>  belonging to the actual session
We set PAM_XDISPLAY ourselves, so we can just make sure we set it to
the spawned X server (we probably don't get that right at the moment
though)

> - if there is only one screen saver server, who gets to configure the
>  it? :-D
>  no, seriously. some users will complain if only root can configure
>  "their" screen saver. this is only an issue for actual multi-user
>  systems, of course.
We could keep the screensaver part on the session vt, and have the
unlock part on the factory vt.

Although, another question is how gnome-screensaver fits in with e.g.
gnome-shell, but I guess that's a different discussion.

> i actually wonder how to integrate fast user switching with screen
> locking. the basic switching interface (outside an active session)
> should be most probably just a login screen with the list displaying
> which users already have active sessions, and the cursor focus the user
> who's session was last active.
Yea makes sense.

> but i wonder whether one should get straight into that mode or whether it should be reached via a separate
> menu point from a more classical "user bound" screen lock.
If the factory is already running, doing the switch immediately
probably makes sense, since it should be quite fast.

If we didn't go with an always running factory then the user might get
confused when their computer locked up for a second as a new X server
started, so having it behind a dialog would make more sense. But
having an extra dialog or a seconds of unapproved lock up both seem
pretty unfriendly.  I still think having the factory running all the
time is probably the way to go though (and if its not running revert
to the existing screensaver unlock dialog).

Too bad we don't have wayland... This would all be a lot smoother with it.

--Ray