Brian Cameron wrote: > http://mail.gnome.org/archives/screensaver-list/2008-January/msg00003.html > > At the risk of encouraging more Linux-bashing, reading this thread you > will notice that the Linux community seems to think that the Xserver > supporting something called XACE (X Access Control Extension) and > labelled objects will address these issues. I'm not sure if they are > considering a11y, nor am I sure if XACE will be supported on Solaris.
Regardless of wither this is XACE or some other Xserver security extension I'd say that is step towards a better architecture. > Since the lock screen program requires a backend daemon running as > root which actually talks to PAM, and since this root daemon should > have access to the Xauth keys for each display, it shouldn't be hard > to make lockscreen work like this: > > 1) The user runs lockscreen, which runs any eye candy background as > the user Agreed the eye candy should run as the user. > 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. > 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. > Java is also accessible. You could also write a dialog using > a widget-set that doesn't support ATK (such as Motif or X11), > but hack the dialog to generate appropriate ATK events as the > user interacts with the GUI. Though this last option could be > a lot of work, even if you only implement ATK for the small set > of widgets that a lock screen dialog would require. The "a lot of work" is the issue though. > 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 ? -- Darren J Moffat
