wayland screen locker and security in general

[Michal Suchanek]

On 6 April 2011 20:57, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Wed, Apr 6, 2011 at 12:55 PM, 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.
>
> I prefer very simple protocol without much modularity. There is

Yes, the protocol should be simple and allow for the compositor to be
also simple and concerned only with compositing, nothing else. That
way you can avoid compositor modules or hacks like executing specific
binary for a specific extra feature (like a screensaver).

> nothing that you want that can't be done, you can for instance have
> the compositor grow it's own modular/protocol system if it see a need

If it can grow it need be defined how.

> for it. But in my opinion is best to keep core wayland as simple as
> possible rather than trying to encompass all usecase.

Hence the need to allow applications external to wayland core do
privileged tasks.

Also if the protocol does not allow at least what current windowing
systems allow then you are making wayland to require extensions of
extensions like X has, from the very start.

>
>>> 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?
>
> You get me wrong, the feature i describe is an example, it's usefull
> only in certain cituation (work station) where things like fullscreen


I know exactly what feature you wanted to implement here - a trusted path.

Why is it useful on a workstation and not my home PC?

If a workstation can have a security feature so can my home PC, it's
just a matter of saying what is allowed and what not.

I can trust my media player to not send my password somewhere if I
accidentally played a video that shows a password dialog in fullscreen
and did not notice that it does not react correctly to what I am
typing on the keyboard. After all it is not designed to capture
keyboard input.

But if the decision what is trusted and what is not is hardcoded in
the compositor I just have a reason to implement a workstation
compositor and a HTPC compositor which are different, so I will
definitely need more than one.

> app are not meant to be use (i don't think any company pays its
> employee to watch movie on there computer). This feature is only

You know, there are also workstations on which movies are *made*.

> doable if compositor is always in charge and no one can do thing
> behind his back and i think it's a very important feature (having
> compositor king of the hill).
>
>>>
>>> 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.
>
> vnc client & rdesktop like feature can and should be in toolkit, not

So if I wanted to access my PC through vnc and was running a mix of
GTK and QT applications I need to run two VNC servers, one for GTK and
one for QT?

> in compositor, not as wayland protocol. Hotkey link are somethings
> easily integrable with compositor and doesn't need much code.
>
>> 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
>>
>
> So you want any application to be able to become wayland king and do
> everything it please, to me it sounds like a very bad idea, again i


No, I want every application to be able to receive a right to do
*something*, not *everything*.

A king does not and cannot do everything in person, he needs officials.

Hence wayland needs to be able to name its officials or it fails as a king.

eg screen lockers need to be restarted on PAM upgrade. If you aren't
able to grant an application the right to be a screen locker you have
to shut down your session on PAM update or be never able to unlock,
The same if the screen locking is implemented inside the compositor.

> prefer having compositor in charge and thus having a "small" codebase
> to audit rather than fearing the worse from every client.

Your idea of having small codebase to audit is to have everything in
one huge monolith. I beg to differ.

Thanks

Michal