GNOME.org
 

Re: [gdm-list] gnome-screensaver authenticates users through GDM

于 2010-1-16 1:06, Brian Cameron 写道:


Jeff:


I'm from Sun Beijing Desktop team. Now I'm trying to port
gnome-screensaver to Solairs.

On Solaris, a process of the normal user can not authenticate users
through PAM, it must be a suid program or a root program. Since GDM
already has a process that can do that, do you think that
gnome-screensaver
can make use of the interfaces of GDM to authenticate users? If
possible, could someone give some hints how to do that?


The GDM process that talks to PAM is gdm-session-worker. The PAM and
Audit steps are a bit different for a normal login than for lockscreen,
but it probably wouldn't be too hard for GDM to be made smart enough to
keep track of which mode it is in and to handle these minor
differences. I would say 95% of the PAM interactions are identical, so
keeping all PAM-related code for login and lock screen in one place
does seem like it would be more simple and maintainable in the long
term.
After looking over GDM code, I knew that GDM login process implements a state machine. For simple greeter login process, you can refer to http://live.gnome.org/GDM/NewDesign?action=AttachFile&do=view&target=gdm-simple-slave-flow.pdf
Another different state machine needs to be impelmented in GDM for gnome-screensaver. This means the architecture shoule be changed for gnome-screensaver. 


There are two approaches that I think could be used:

1) gnome-screensaver becomes a program which just keeps track of
when the session is idle long enough to lock the screen, does
the screen lock and shows eye-candy. When the user hits a key or
moves the mouse, it would send GDM a D-Bus message telling it to
displays the normal GDM login window to ask the user to
authenticate. This would cause GDM to start the login dialog with
the lockscreen PAM stack so it just asks for the password (or
whatever the lockscreen PAM stack is defined to do).
Not login dialog, since username is not needed. I guess a new dialog may be needed or the old login dialog 
needs to hide username with a different flag.


This approach has many advantages. It means that only GDM needs
to know about how to present the authentication dialog and handle
PAM interactions. Having a single program handle the GUI is nice
since this means that there is only a single dialog that needs to
be made to work with a11y. Since GDM has good a11y support, it
would be nice to leverage that.

Another advantage is that on the console, this could be written so
the authentication dialog screen is presented on a separate VT and
runs as the "gdm" user, providing better TrustedPath security. This,
for example, ensures that the authentication dialog is not using
the same Xauth cookie as the user's session, avoiding any possible
interference or snooping from a userland program.

2) gnome-screensaver just calls gdm-session-worker D-Bus interfaces
to do the actual PAM interactions. You really do not want any
program to be able to access these interfaces, so it would need
to be implemented in such a way that only "approved" programs
like gnome-screensaver could call these interfaces. This approach
has the advantage of consolidating the PAM code in one place, but
means that gnome-screensaver still needs to manage all GUI related
things such as a11y. Also, this solution would not improve the
TrustedPath situation at all.

I imagine that new D-Bus interfaces would need to be added to
gdm-session-worker to make this work, but I'd think it should be
possible. And it could be a step towards implementing solution #1
in the long-term.


I've heard that Jon McCann had ever planned to integrate the functions
of gnome-screensaver into GDM. But it may need a long time. So before
that, as the first step, GDM can provide PAM authentication
interfaces that allow others use them.


At the GUADEC in Istanbul, Jon suggested that solution #1 above was
something that he was thinking about implementing, though I think
Jon is more focused on gnome-shell these days.
#1 is the best solution which can solve many problems that have been exitsed for a long time. 
Maybe we can go for this goal now.

Jeff


Brian
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]