wayland screen locker and security in general

[Michal Suchanek]

On 7 April 2011 02:00, cat <zixon65 at gmail.com> wrote:
>
>
> On Wed, Apr 6, 2011 at 11:57 AM, Michal Suchanek <hramrach at centrum.cz>
> wrote:
>>
>> On 6 April 2011 18:34, Jerome Glisse <j.glisse at gmail.com> wrote:
>> > 2011/4/6 Michal Suchanek <hramrach at centrum.cz>:
>> >> 2011/4/5 Kristian Høgsberg <krh at bitplanet.net>:
>> >>> On Tue, Apr 5, 2011 at 5:59 AM, Michal Suchanek <hramrach at centrum.cz>
>> >>> wrote:
>> >>>> Hello,
>> >>>>
>> >>>> what is the plan for screensave/screenlocker support in wayland?
>> >>>>
>> >>>> The support in X is a fail in several ways.
>> >>>
>> >>> It sure is.  The plan for Wayland is that the lock screen is just part
>> >>> of the compositor.  There are no problems with detecting idle or other
>> >>> applications having grabs this way, and the compositor completely
>> >>> controls what goes on the screen so you don't have other applications
>> >>> raising their window over the screensaver.  There doesn't even have to
>> >>> be a screensaver window, the compositor can just paint a black screen.
>> >>>
>> >>> It is of course possible to define a plugin or an out-of-process (fork
>> >>> a special Wayland client and give it a special surface to render to,
>> >>> similar to your second option below) mechanism for rendering fun
>> >>> screensavers.
>> >>>
>> >>
>> >> IMHO having anything that requires somewhat uncommon functionality as
>> >> part of the compositor is lame. The same if a new plugin is required
>> >> for any new function somebody comes up with.
>> >>
>> >> Eventually there should be multiple compositors to choose from and
>> >> they should *not* each include everything and the kitchen sink.
>> >>
>> >> Thanks
>> >>
>> >> Michal
>> >
>> > I don't think it's lame, a good compositor with good theming
>> > capabilities and you will only need one. Moreover you can add very
>>
>> Seriously, it's not just look what makes the difference between a good
>> window manager and a bad one.
>>
>> Maybe with wayland there is need only for one but I doubt that, there
>> is no one-size-fits-all application of any kind I know of.
>>
>> Yet if you insist on the compositor doing anything that a "normal"
>> application is not allowed to do instead of a modular system that
>> allows authorizing applications to do something you effectively make
>> developing a new compositor very hard, and switching between different
>> compositors as well.
>>
>> > usefull feature in the compositor regarding locked screen, for
>> > instance you can force the compositor to always composite a small
>> > picture (some kind of icon) on top of fullscreen app so no app can
>> > malisiously present itself as being a screensaver and spy on user
>> > password. Only the compositor would paint without the icon. This is
>> > just one example.
>>
>> Sure. Or you could grant your movie player the privilege to paint
>> without an icon as your screensaver does when you are bothered by it.
>> But that requires putting the movie player into the compositor, eh?
>>
>> >
>> > I think wayland design is to avoid redoing X and trying to add new
>> > protocol for screensaver or whatever new application one might come up
>> > with, is to be avoided. Of course that means that piece like the
>> > compositor will have to include bunch of code that were previously
>> > "standalone".
>>
>> Oh, so also VNC client and server must be in the compositor (to spy on
>> and inject events), and so must be x2x (or w2w), any application that
>> needs to manipulate clipboard in unusual ways (such as providing
>> format conversion), and the hotkeys application that launches your
>> media player when you press |> on the keyboard. And rdesktop that
>> requires raw keycodes.
>>
>> And a bunch I missed, I am sure.
>>
>> It's not like it should be a separate scrensaver protocol. It should
>> be a protocol that any application can use to do its thing.
>>
>> Thanks
>>
>> Michal
>
> my understanding is that wayland is suppost to  be a simple protocol, not
> the end all be all hub of the desktop, attributes could be nice but  I think

Still it should be designed such that it fits somewhere in the "end
all be all hub of the desktop" otherwise it will be a piece that fits
nowhere in it, just like the X server.

> the overall result is that things like screen locking should be left up to
> the implimentation. wayland needs to be a base for putting stuff on the

They should not. Wayland should come with a screenlocker and an
obvious and documented of for plugging a different one.

Otherwise you will get a hell of mutually incompatible solutions.

The X server has some 2-3 screensaver protocols none of which is
usable, and there are about 3 separate protocols to talk to the
screensaver outside of the X protocol because the X protocol is not
made to convey the information the screensaver needs.

> screen and giving input. screensavers could be setup to work different
> viewports or a second protocol could be used to operate the many features of
> the desktop
> the server could keep a whitelist of programs that inhibit the screen while
> running so that a malicious program doesn't leave the screen unlocked for
> intruders or scrape your password. There are some situations that these
> programs/features don't make sense .
> so that

No, wayland itself should not be concerned with  screen locking,
screen locker should.

However, wayland should make it possible for a screenlocker to do its work.

And while it is possible to just hack in an extension that will make
it possible to do a screen locker it would be much nicer if the
protocol itself was flexible enough that things like vnc server or
screensaver could work using the same generic protocol without the
need for an extension for every new kind of application.

Thanks

Michal