Darren: >> 2) When the user hits a key or moves the mouse, a message is sent to >> the daemon telling it to pop up the dialog. Since the daemon is >> running as root, and should have access to the Xauth key for each >> display, it should be possible to launch the dialog as another >> user (say the "gdm" user which is designed for UI's that accept >> passwords), and also run with the Security Extension to prevent >> Xauth snooping. It's a bad idea, in general, to run GUI's as >> root, so I think using a user like the "gdm" user makes more >> sense. > > Why can't the X server do the GUI part too ? > > We don't need eye candy in the GUI part. We do however need A11Y and > that is a problem that the GTK+ toolkit solve for us.
My understanding is that to provide Trusted Path, you need to remove the possibility for anybody to snoop, modify, affect, etc. the password that the user enters. Therefore, I was under the impression that you needed to run the lockscreen GUI as a different user, to prevent another (malicious) program running as the same user from being able to snoop, modify, affect, etc. the password value as it is being entered. Is this not the case? Likewise, Xauth has a similar issue. My suggestion of running the process with the Xserver Security extension with a separate connection to the Xserver should address this issue. In terms of a11y, it does complicate things if the dialog is running as a different user with a different Xserver connection. The existing a11y infrastructure isn't really designed to work this way. However, it would probably be a good idea to fix this, and figure out how to make a11y work with more secure dialogs, the Xserver security extension, etc. The solution to this problem that I suggested is simply embedding the needed a11y infrastructure into the dialog. Though I'm very interested to hear if people have other suggestions. >> One idea that I have tossed around a few times, though not in this >> forum would be for the GDM daemon to be this background daemon. >> Since GDM already knows about PAM, audit, etc. it might be nicer >> to have just one daemon running than two. I realize PAM, audit >> is done a bit differently for login versus lockscreen, but I'd >> think it should be possible for GDM to be smart enough to handle >> either case. > > That seems reasonable and isn't that dissimilar to how CDE did it. > Instead of it being dtlogin it was dtsession but a similar idea. Right. It does have the nice "one daemon is better than two" feature. However, dtsession has all the xauth security issues that xscreensaver has. >> 2) Instead of providing magnification, it might be sufficient to >> just provide a hotkey that increases/decreases font size in the >> dialog. And the ability for the user to configure the default >> font size. > > Or given how little info is on the screen why not always use a > sufficiently large font ? In my experience, it is usually best to make such things configurable. It's hard to predict what is "sufficient" for all types of disabilities. But your point is valid - there is more than one way we can meet a11y requirements. Brian
