Re: [gdm-list] how to use authentication feature of GDM in a screen saver
- From: Ray Strode <halfline gmail com>
- To: Jedy Wang <Jedy Wang sun com>
- Cc: mccann jhu edu, gdm-list gnome org
- Subject: Re: [gdm-list] how to use authentication feature of GDM in a screen saver
- Date: Thu, 8 Apr 2010 16:12:27 -0400
Hi,
On Wed, Apr 7, 2010 at 4:29 AM, Jedy Wang <Jedy Wang sun com> wrote:
> The solution I currently have is to add a DBus method (in SimpleSlave maybe)
> which the screen saver process can call to obtain the private bus address,
> then the process can use the address to connect to GreeterServer and do
> authentication staff. But I am not sure if this is a good idea because any
> process in the session can obtain the address and may monitor the traffic on
> the bus. So I wan to know if this is a acceptable solution for the community
> or if there are any better ones?
I haven't thought about this very hard yet, but I don't think that's
conceptually the right approach. The GreeterServer is an interface
for serving the greeter. The screensaver isn't a greeter, so I don't
think it's the right way to go.
I can give you a bit of a brain dump, but I don't have all the answers
or the time atm to investigate.
Every logged-in session has an associated session worker running in
the background. This is the worker that processed the pam
conversation that initiated the log in, and it's waiting for the
session to end to do a proper pam_close_session.
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.
One feature GDM has started implementing but is currently commented
out is gdm "factory mode". The way this works is there is always a
greeter on vt1 (or maybe vt7 depending on how you have things
configured). Whenever you login, the session is started on a brand
new vt, and the greeter sticks around on its vt. Anytime the user
switcher is used, it just jumps back to the greeter vt to process the
user switch. If we used factory mode, then unlock could be just
another form of user switching. Instead of locking one active session,
switching to the greeter, and then unlocking another session, it's
locking one active session, switching to the greeter, and then
unlocking that same session.
Make sense?
--Ray
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]