Re: Questions about PAM, GDM and gnome-screensaver

[Brian Cameron <Brian Cameron Sun COM>]

Ted:

> This thread got a little lost at the end of the year (happy New Year
> everyone!), I wanted to try to summarize my understanding (to see if I'm
> understanding right) and to see if everyone agrees :)
>
> Issue:
> The Sun folks want to have a trusted path of processes talking to PAM,
> which basically means processes that can't load user specified modules.
> This would include things like GTK+ themes, image loaders, etc.
>
> Plan:
> Create a DBUS interface to service that would actually be the person
> controlling whether the display is unlocked.  Likely this would run
> under the GDM user.  The permission aspect could be controlled via
> something like PolicyKit.
>
> Is that the idea in a nutshell?

I don't think we've yet agreed on a plan, but I think you have
summarized the issue fairly well.

That said, there are a few remaining issues:

1) Since the lockscreen runs in the user's Xserver, there are
   ways to snoop or corrupt the password via X interfaces.  There
   doesn't seem to be an easy answer for fixing this.  Making
   the Xserver GrabServer has been mentioned, but isn't a great
   solution.

2) If PAM isn't run as the user, then PAM won't refresh credentials
   that are in userspace (e.g. a Kerberos credential in
   gnome-keymanager).  On Solaris, where we don't run PAM as the
   user anyway, this proposal doesn't break things any worse than
   it currently is.

3) There are probably situations where the existing behavior of
   running PAM as the user is desirable (perhaps on Linux), so
   it is probably desirable for it to be possible to configure
   which user actually interacts with PAM.  On Solaris this should
   probably be a user with enough privilege to interact with PAM
   (and not the actual user locking the screen).  On Linux it is
   probably okay to run as the user locking the screen.

4) This discussion may just be theoretical since I don't get the
   impression that all the parties involved really agree how this
   should be done.  Though, the more we discuss, the more likely
   we will converge on some clever idea perhaps.

Brian