Nicolas: > 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.
This is probably a discussion that needs to be had with the gnome-screensaver maintainer. His name is William Jon McCann, and he is involved with doing the GDM 2.21 rewrite which uses D-Bus for interprocess communication. I suspect he wants to use D-Bus for various interactions because he wants programs like GDM, lock screen, fast-user-switch applet (FASA) to be able to talk to each other to manage things like VT switching in a common fashion. However, perhaps we can argue that sockets makes more sense here. Also, if we want to patch gnome-screensaver to use sockets we are free to do so, even if the patch doesn't go upstream. > (But also, I question the need for privilege separation here.) The only other option, unless I'm missing something, is for the lock screen GUI to run as root. This is not recommended to do with GTK+ based programs, and GTK+ is needed for a11y support. Plus, it is probably not a good idea to run GUI's as root anyway. >> 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 am just under the impression that he will want to use D-Bus because he likes to use it for interprocess communication. We haven't really talked with him about it yet. I just mention it because, as I said, I think he will want to use D-Bus. >>> 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. If Alan is correct that Trusted Path is really only a requirement in Trusted Solaris, and that these issues are dealt with by other means (the Trusted Xorg extension, etc.) then perhaps this is not an issue. Brian
