Re: WM enhancements to support accessible screen lock

[Bill Haneman <Bill Haneman Sun COM>]

Lubos:

Since in X passive grabs are exclusive of other passive grabs,
applications that aren't in the foreground (with the exception of window
managers and 'special' applications) should not make them.  I think this
invalidates your point; "special" applications like FVWM need to be
trusted anyway.  So applications which would be able to circumvent a
lock-screen pointer grab fall into three categories:

(1) special/trusted apps like the WM;
(2) ill-behaved applications;
(3) trojans.

IMO applications in category #1 are a non-issue (they need to be smart
enough to work well in lock-screen situations), applications in #2 need
to be fixed, and applications in category #3 can use other sniffing
techniques.

So I am very unconvinced by your examples ;-)

> > Can you provide some examples?  I don't know of any situations where you
> > can meaningfully accomplish anything if the WM is preventing
> > applications other than the screensaver/lock programs from taking focus
> > and being in the foreground.  Applications don't normally receive mouse
> > events unless their XWindows are visible, and as we've already
> > discussed, other ways of getting mouse info (besides normal X pointer
> > event delivery) can circumvent the lock anyhow.
> 
>  Mouse button grabs. That's how other applications can get mouse events, 
> unless the pointer is grabbed. And it's not really the same like those other 
> ways to circumvent the lock, I'm talking about normal applications that the 
> user could normally run, not some sniffing tool.
> 
>  To be specific, I'm talking about gestures (also known as strokes or 
> whatever). E.g. FVWM has support for them AFAIK, and since FVWM is 
> extensively configurable, I'd guess that they can perform a lot of things in 
> FVWM. Also with KDE3.2 there will be a utility that will be able to do 
> basically anything after performing a gesture as well.
> 
>  And I don't really consider pointer grabbing that problematic. The locking 
> app can simply detect which window is at the event coordinates, and forward 
> the event to the appropriate window if it's necessary. Is this really more 
> complicated that trying to check and adjust all apps that have global input 
> triggers?

It is, especially if you are talking about xscreensaver, where new
dependencies will be resisted strongly.

> > > Moreover, the reasoning
> > > that grabs are actually useless was based on claiming that one can run
> > > apps that will get some information about the input even if the pointer
> > > is locked. However, I fail to see how such apps could be run with input
> > > grabbed (and if somebody lets somebody else to run it while the screen is
> > > not locked, it's not really the lock's problem).
> >
> > The same could be said for applications that subvert the WM's efforts to
> > manage X focus, or otherwise 'allow the user to do things' when their
> > application X windows are obscured by the lock and/or screensaver
> > windows.
> 
>  See above. Some applications check user input even if they're not shown at 
> all.

My point exactly;  such applications are either "special, trusted apps",
in particular the WM which is the logical agent for enabling the
behaviors we need and for respecting focus priorities, or they are
ill-behaved.  A background application has no business acting on a
passive pointer grab in a way that compromises screen-lock security.

- Bill
 
> -- 
> Lubos Lunak
> KDE developer
> ---------------------------------------------------------------------
> SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
> Drahobejlova 27  tel: +420 2 9654 2373
> 190 00 Praha 9   fax: +420 2 9654 2374
> Czech Republic   http://www.suse.cz/
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list