[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Re: Re: Security Audit Request for Screenlocker Branch
From:       Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= <mgraesslin () kde ! org>
Date:       2011-10-12 10:10:48
Message-ID: 1822109.h4GTisxvVM () martin-desktop
[Download RAW message or body]


On Wednesday 12 October 2011 09:10:40 Oswald Buddenhagen wrote:
> > Of course KWin is a more complex application than others, but given
> > what we need in a screen locker the difference becomes marginal IMHO.
> 
> yes. one should consider decoupling the greeter from the core engine.
> 
> > > > I myself have never run into a situation where KWin did not restart
> > > > [...]
> > > 
> > > even if it restarts, you still have a non-trivial racing window.
> > > additionally, it probably allows a waiting app (some popup) to grab
> > > input and thus make the subsequent re-lock fail.
> > 
> > ok, this is a concern I have not yet considered. Any ideas how we could
> > handle such a situation?
> 
> by not crashing in the first place. seriously. think about it.
ok I have been thinking about it and have a new proposal:
* writing a kded module to only handle the screen locking (grab keyboard and 
mouse)
* having greeter in a separate process, so that the kded module can restart 
the greeter in case it crashes
* use xproperty on all greeter windows to inform the compositor which windows 
belong to it
* use a kwin effect to additionally ensure that the screen is blanked and 
nothing gets above the greeter windows

Thoughts?

Cheers
Martin
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]