On Thu, Mar 06, 2008 at 03:55:26PM -0600, Brian Cameron wrote: > >On Thu, Mar 06, 2008 at 03:35:01PM -0600, Brian Cameron wrote: > >>So really this PAM issue is a non-issue. We just need to make it > >>possible to configure gnome-screensaver this way to move forward. > >>Since the gnome-screensaver author loves D-Bus, I suspect he would > >>want the IPC communication mechanism to be D-Bus, which seems > >>reasonable. > > > >IPC for what? > > Communication between the lock screen GUI running as the user, and > a backend daemon that runs with authorization and talks to PAM.
Why?! This will greatly complicate things. Those two processes are intimately related and should use something simple for IPC between each other. (But also, I question the need for privilege separation here.) > xscreensaver basically works like this, but I believe it uses a > sockets pipe for such communication. Which is jsut fine. Why bring all of DBus into this picture?! > >I think fixing this in the X11 protocol would be more appropriate. > > > >E.g., an operation for grabbing the display's I/O devices that only a > >privileged caller could execute (after xauth is done). This, of course, > >would mean that the screen lock process that talks to the X11 display > >would have to have some privilege that normal user processes don't. > > So does this mean that the security team is okay with this aspect of > Trusted Path just not working with lock screen programs until the > issue is fixed in X11? In other words, we don't need to address > this in porting from xscreensaver to gnome-screensaver (or other > screensavers). I have no idea if there's consensus for that in the security team. I'm not familiar enough with the screen lock trusted path issue to make up my own mind, but if, as I suspect (at *very* first glance), the only foolproof way to resolve that is to extend the protocol, then I'll support your suggestion. Nico --
