[gdm-list] GDM in multi-display mode and as lock screen

[Brian Cameron <Brian Cameron Sun COM>]

Over the past two weeks, I have been working with the Sun Ray team
and helping them integrate better with GDM.  We did a fair bit of work
exploring different options with GDM and I wanted to share what we
covered and discovered with the rest of the GDM community.

1. Sun Ray and GDM 2.22

   I think the GDM community will be happy to hear that we were able
   to get Sun Ray working fairly well with GDM 2.22.0.  The reason
   this is exciting is because it demonstrates that GDM works well
   in a multi-display mode.  We tested with about 10 displays running
   at once, and it seemed to work great.

   To get SRSS working, we had to patch GDM 2.22.0 to work with the
   PreSession and PostSession hooks, which had not yet been enabled
   in the rewrite.  I was able to get a fix for this upstream into
   GDM SVN head [2].

   We did our testing using the gdmdynamic patch which is now available
   via bugzilla [1].  I believe this is the only way, at the moment, to
   make GDM 2.22.0 behave in a multi-display fashion.   We did find some
   minor usability issues, though.

   We noticed, for example, that g-s-d seems unable to draw the
   background on any display except for DISPLAY :0.  All other displays
   have the gray Xserver default background.  We also noticed that when
   GDM doesn't find any users to display in the face browser, that the
   GUI dialog seems to have problems resizing itself.  Hitting the
   "Cancel" button, for example, would cause the dialog to resize so
   thin that you could no longer see what you were entering in the
   text entry field.  Perhaps the fact that the "Reboot" and "Shutdown"
   buttons are turned off by default on Solaris caused these sorts of
   problems to be more visible.

   So this means that if people using SRSS on Linux want to try out
   running SRSS with GDM 2.22.0, it seems to work fairly well - at
   least for testing and development purposes.

2. Using GDM as a lock screen program

   From October, 2007 through January, 2008 there was some discussion
   about the merits of using GDM as a lock screen program and about
   how Trusted Path applies to lock screen [3].

   The Sun Ray team wants to use GDM as a lock screen program because
   they have several issues using the default gnome-screensaver or
   xscreensaver lock screen program.  Their main issue seems to be
   that there are situations like when a user opens a GTK+ menu, this
   causes a screen grab from the GTK+ program.  Then if a user pulls
   out their SmartCard, the screen lock program fails to be able to
   lock the screen since the screen is already grabbed.   Leaving the
   session in a non-locked state is a serious problem, so to solve
   this they wrote their own lock screen dialog.  Now, when a user
   tries to re-connect to their previous session, the Sun Ray server
   will create a brand new Xserver session which only is running their
   lock screen dialog as the root user.  When the user authenticates,
   this session is destroyed, and the user is reconnected to their
   real session.  By isolating the screen lock in a separate session
   they avoid worrying about how to manage dealing with any existing
   screen locks in the user's session.

   I understand that the GDM 2.22/2.23 developers are considering a
   similar approach for handling lock screen in the future.  It would be
   interesting to hear what thoughts and designs (even if very
   preliminary) are being considered, so we can work better together.

   Obviously showing the lock screen dialog in a separate isolated
   session (rather than the user session) is more secure - especially if
   the GUI dialog is running as a different user.  To support a11y in
   a Trusted Path fashion, you really want any a11y tools needed to
   navigate the login screen to also run as a separate user.  Otherwise
   it is fairly simply for trojans to snoop on or interfere with the
   lock screen dialog - violating Trusted Path.

   Now the Sun Ray team wants to replace their existing lock screen
   dialog with GDM, so that it has accessibility support (amongst other
   reasons).  Working with them, we were able to get this to work with
   GDM 2.20 with only a little work.

   Since GDM supports per-display configuration, they specify PamStack
   for the given display, specifying a lock screen pam stack.  This
   alternative pam stack pre-fills in the username so that GDM only
   asks for the password.  Then they use the PostLogin hook to terminate
   the login dialog and trigger the display to be reset to the actual
   user session after authentication.  They also use per-display
   configuration to specify a different gdmgreeter theme which avoids
   showing buttons and menu choices that do not make sense when being
   used as a lock screen.

   So, it was neat to see that it was not much work to make GDM work
   as a lock screen dialog.  However, I see that using PamStack in a
   per-display fashion is not really the ideal way to make this work.
   Obviously it might not work well if the user has many Xnest displays
   running on the same display, for example.  This is not a bother for
   Sun Ray since they don't support Xnest GDM.  But if we want to
   support this kind of feature in GDM moving forward, a more clever
   way of configuring which PAM stack to use when launching the GDM
   GUI.

   The only serious problem we found with using GDM 2.20 as a lock
   screen program is that it is not auditing properly.  GDM obviously
   needs some mechanism so it knows to audit differently when acting
   as a login screen versus a lock screen.

   So, in summary, this work made me realize that to make GDM act as a
   lock screen, you really only need a few additional features:

   - The ability to specify an alternative PAM stack when launching a
     GDM GUI.
   - The ability to specify that auditing should be handled differently
     when doing lock screen versus login.
   - The ability to inform the GDM GUI to display itself a bit
     differently to avoid showing options that do not make sense at
     lock screen time.
   - On Linux, where you want PAM to run as the user when handling
     lock screen, the PAM code would need to know to drop to user
     ownership and permission when authenticating lock screen.

   I think the main advantage of using GDM as a lock screen dialog
   is simply because making Trusted Path, accessibility, PAM, audit,
   etc. all work properly together is hard.  It is obviously easier to
   just centralize this code in one place rather than in multiple
   programs.  Since, for example, GDM will likely have a rich set of
   mechanisms for launching a11y features, it seems best to have this
   sort of complicated logic in one place.

   I do not think that it is necessarily essential for Sun Ray to
   support lock screen via GDM.  If a different approach is developed
   that resolves their underlying problems, I am sure the Sun Ray
   team would be happy to more simply use a more general approach
   rather than having their own custom solution.  However, I think
   that using GDM also as a lock screen program is an interesting
   idea, and I wanted to let people know that it was pretty easy to
   get GDM 2.20 to behave as a reasonably functional lock screen
   dialog.  This does not yet work as well with GDM 2.22 since there
   is obviously no way to specify a different PamStack value when
   launching a specific GDM GUI.

Brian


---

[1] http://bugzilla.gnome.org/show_bug.cgi?id=536355
[2] http://bugzilla.gnome.org/show_bug.cgi?id=536371
[3] 
http://mail.gnome.org/archives/screensaver-list/2007-October/msg00000.html
http://mail.gnome.org/archives/screensaver-list/2007-November/msg00000.html
http://mail.gnome.org/archives/screensaver-list/2007-December/msg00003.html
http://mail.gnome.org/archives/screensaver-list/2008-January/msg00000.html