wayland screen locker and security in general

Michal Suchanek hramrach at centrum.cz
Tue Apr 5 02:59:03 PDT 2011


what is the plan for screensave/screenlocker support in wayland?

The support in X is a fail in several ways.

First off there is no way to select all events. While you can spy on
mouse position or key events you can't spy on mouse events so the
screensaver activates when only mouse buttons/wheel are used.

Second the way to lock the screen is to grab the X input (pointer and
keyboard) so that other applications can't get them while the screen
is locked. This fails when a grab already exists because X has only
one grab and it is acquired on first-come first-serve basis. A
technical issue with X protocol also requires the grab to be taken for
pulldown menus and drag and drop operations in any application.

Third is that you can't cover the screen. xscreensaver creates a
fullscreen window to show the cool effects (or cool blackness) and
raises it to top but subsequently created windows can get on top of
it. xscreensaver works around it by raising the window every few
minutes but there is no way to ensure that the screen is covered.

There are other issues as well. In X any application can allocate any
amount of pixmaps eventually crashing the X server.

There should be a mechanism that allows limiting the damage a single
application can do.

There are several options here.

One is to have some policy in the wayland server/compositor eg people
suggest that applications should not be able to lock the screen, and
the screenlocker binary be in a specific place, the wayland compositor
implements a toolbar with a lock button, and whenever the button is
pressed that binary is executed and granted the privilege to lock the

Another option is to use a proxy. The compositor and screenlocker
would connect to the server directly while applications would connect
through a proxy that denies some requests. The proxy can implement
some policy like allowing up to 5MPix of screen data in up to 5
windows refreshed up to once per vsync.

Yet another option is to have policy advisor to which  the server
talks through a separate connection. Whenever an application sends a
request to the server it asks a policy advisor if the request should
be honored.

Compared to the proxy solution there are advantages and disadvantages.

The disadvantage is that the server has to process even requests that
are denied.

The advantage is that the server can talk to the application directly.
eg the application selects some events, the policy allows selecting
them, and then the application can receive events directly.

A non-trransparent protocol could have advantages of both. The
application first talks to the policy server, and if the request is
allowed it gets a handle which can be used to perform the request on
the display server, input driver, or whatever other component
implements it.

With either the advisor or the proxy the policy can be dynamic and
negotiated between the advisor and the application by arbitrary
protocol independent of wayland protocols. With either the system
fails when the policy component fails - either the proxy goes down and
stops forwarding requests and repliesor the advisor goes down and
every new request is denied.



More information about the wayland-devel mailing list