Moving the screenlocker into compiz

screensavers and screenlockers are tricky.

They’re tricky because they’re a double edged sword from a security perspective. When one is around, you had better not let anything else get on top of it, but also, you had better not let anything else pretend to be a screensaver either, (that is, unless your application is a “screensaver” and now suddenly gets to be on top of absolutely everything).

So it’s no surprise that there’s a general movement to kill these external screensavers and put them somewhere else where they actually have a little more control. That is, inside the compositor. This is mainly for security reasons, see, in Window Manager land, we have no such concept as a “screensaver” window or a “screen locker window” – the closest thing we have is the concept of fullscreen windows and windows which hog all the input (grabs). So, screensavers are kind of an amalgamation of the two. Except that things can still go above them (note the use of the word “focused” in relation to fullscreen windows, yeah, interpreting the EWMH is like interpreting a complicated contract sometimes [well, it is kind of a complicated contract, but that’s a discussion for another day]).

So along came the XScreensaver extension which was all well and great because it allows you to “bless” one window as the screensaver and that was it, it went on top of everything. Of course, the problem there is that it’s tied to X11, and given that most DE’s want to go multiplatform this isn’t something that’s really feasible.

And that means that the next best thing is a hack. A really really big hack. The hack is something like this

Nothing shall ever get on top of me. If anything tries to get  on top of me, I will just ask to be on top of them. Nothing. Shall. Pass. Ever.

Oh, and just in case something did get on top of me, every so often I’m going to make sure that I’m on top. Yeah, I’m awesome

(reflected in the code here)

This is probably not the best application design practise that we should really be encouraging, because the message is that in order to write anything secure you basically have to abuse the window manager and hope it does what you want in order to do anything useful.

If we move the screen locker into the compositing manager, it means that the compositor can now absolutely ensure that the screen locker is always on top by ensuring through the magic of SubstructureRedirectMask that nothing ever gets on top of the screen locker in the first place. Which is pretty awesome, and a lot more simple.

So great. Now I wondered to myself, how the heck can we implement this? Doing an entire screen locker inside of a window manager seems like a bit of an insane task to me, since it means dealing with a number of security frameworks, secure keyboard input etc. And we already have the other screen lockers at our disposal, do we really need to rewrite them for every window manager?

Well, as it turns out, there’s a fairly simple hack that we can do for this. Have compiz handle the blanking of the screen via communication with an external “locking” service, have a separate application (eg gnome-screensaver) handle the input and dialog side of things and get the service to bless the dialog as the locker window and have compiz handle the disabling of window painting and disabling of input. And the result:

Oh yeah, you can have pretty animations too. And this finally means that when GNOME and KDE drop the old screenlockers you’ll still be able to use compiz and be secure!

Now how awesome is that?

edit: the code:





protip: don’t install gnome-screensaver-hax unless you want a totally broken system, as you can probably tell, this was a hack to make the locker dialog parent into the compiz locker window and breaks it under normal usage. (It works under compiz though :))


11 thoughts on “Moving the screenlocker into compiz

  1. I am not an Engineer but I follow your posts just because you rock!
    You make things such as screensavers become very interesting. I love the way you logically walk through the issue before you provide us with an intelligent solution.

    You are doing an amazing job and I feel more secure to use Ubuntu knowing that the system is backed up by these very smart guys.

    Greetings from Brazil! o/

  2. Nifty. Can something similar be done with gksu and kdesu? I think it’s really important that those kind of dialogs be visually distinct from normal ones. This way, you’d emphasise that the system is asking for the user’s password and it’s not just some malicious program asking for their password. Hopefully if such malware were ever to be written it’d set off alarm bells for the user and they’d know that this is not normal behaviour.

    1. Visually distinct, as in, have spotlights move all over the screen, red and blue lights flashing and a siren playing in the background, with shadows cast from the foreground windows to the background windows depending on the angle of the spotlights?

      That’d be spectacular, and I doubt any malware would be able to replicate it. 😉

  3. You say that XScreensaver extension isn’t feasible because of “going multiplatform”, but how is using Compiz any different? It’s more tied to platform (and to X11) than XScreeensaver itself!

  4. Hey smspillaz,

    I would like to know if there is any release schedule for the first stable release of compiz(Probably 1.0? 😉 )

    Currently, I’m using Arch and I would like to enjoy the great peace (and up to date) version of compiz(-fusion) 🙂

    Thanks for the work and keep it up!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s