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

List:       kde-core-devel
Subject:    Re: Security Audit Request for Screenlocker Branch
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2011-10-13 19:50:23
Message-ID: 20111013195023.GA11202 () ugly ! local
[Download RAW message or body]

On Wed, Oct 12, 2011 at 09:39:48PM +0200, Thomas Lübking wrote:
> Stupid question, but since kdm links X11 and communicates with the
> greeter anyway: can we simply have it grab keyboard and mouse (must
> create a window in the session for this purpose, but it runs on root
> privs)
>
using the kdm greeter for that basically equates making kdm handle the
screenlocking entirely. which is a good idea as such.
but consider that the greeter doesn't run while the session is up, so
interaction would come with some delay. one could pre-launch it already
when locking, i guess.
one would probably put the locking engine's input handling inside the
kdm backend (which, btw, means throwing some qt rudiments out of it) and
feed the greeter with events just like the locker's plasma overlay is
currently fed - that would make login time and in-session greeting
pretty much identical.
the greeter isn't necessarily root-owned (when correctly configured),
but it still has the power to wreak some havoc (it's obvious that one
would use the integration to implement early shutdown feedback and
proper fast user switching, which means that the greeter can issue
potentially destructive commands).
the greeter recently stopped grabbing input by default, as that breaks
input aids. this *must* be reverted to allow entry of other user's
credentials. it's likely that the input redirection concept would cover
auxilary windows adequately, just like it does for the plasma overlay.
there are probably some more challenges i haven't considered.

> > > > * use a kwin effect to additionally ensure that the screen is
> > > > blanked and nothing gets above the greeter windows
> > > >
> > that seems superfluous. the presence of the locker window
> > simultaneously indicates "locker mode" and provides "blanking
> > content"
> >
> Yesno, as mentioned w/ active compositing an ARGB window is pot.
> translucent.  At least if the locker window is ARGB, this has to be
> covered by the compositor (but that's a tech. detail about "broken"
> screensavers) by initially wiping the scene and then only painting the
> locker/greeter
> 
right, i only thought about initial blanking. so the effect would
explicitly black out all translucent areas of the main locker window.
i guess that makes sense.

On Wed, Oct 12, 2011 at 09:09:28PM +0200, Thomas Lübking wrote:
> Am Wed, 12 Oct 2011 09:10:40 +0200 schrieb Oswald Buddenhagen <ossi@kde.org>:
> > that's not a response to my question. the old lock engine offers the
> > option to start a saver which only after a few seconds requires a
> > password to make it go away.
>
> I think it was, because the idea is that the locker, unlike today
> savers, does not start automatically. The screen is just turned off to
> save it.
> 
well, that means that i was right, because even the premise for my
question would not be satisfied any more.

> That might however be shortsighted, since it *could* be required to
> cover "stupid" users who just walk away and forget to lock their screen
> while they actually should.
> 
indeed.

On Thu, Oct 13, 2011 at 10:26:39AM +0200, Martin Gräßlin wrote:
> > > > * use xproperty on all greeter windows to inform the compositor which
> > > > windows belong to it
> > 
> > i'm assuming you are including the locker/saver window in "greeter
> > windows"?
>
> Yes, everything "visual" in the separate process.
>
if you make that "process_es_", then it's correct. :)

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