Security Audit Request for Screenlocker Branch

Dario Freddi drf54321 at gmail.com
Wed Oct 12 15:47:54 BST 2011


2011/10/12 Martin Gräßlin <mgraesslin at kde.org>:
> 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)

TBH, if you really care about not making the thing crash, I would not
put it into KDED, which has a lot of things which are not under your
control potentially crashy, but into a separate running daemon.

> * 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




More information about the kde-core-devel mailing list