From kde-core-devel Wed Oct 12 14:47:54 2011 From: Dario Freddi Date: Wed, 12 Oct 2011 14:47:54 +0000 To: kde-core-devel Subject: Re: Re: Re: Security Audit Request for Screenlocker Branch Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=131843090219927 2011/10/12 Martin Gräßlin : > 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