Wayland protocols

[Pier Luigi Fiorini]

On Monday 18 August 2014 18:22:42 Martin Gräßlin wrote:
> On Monday 18 August 2014 17:48:03 Pier Luigi wrote:
> > 2014-08-15 7:35 GMT+02:00 Martin Gräßlin <mgraesslin at kde.org>:
> > > * concerning the lock/unlock: I would like to have the lock way better
> > > integrated in KWin. That is KWin should be responsible for locking and
> > > nobody else. My though is that KWin takes over the screen locker dbus
> > > interface and starts the screenlocker greeter  when it's needed. It
> > > could
> > > pass a dedicated fd to greeter and thus would know that it's the lock
> > > screen surface implicitly. That way we would not need a protocol at all
> > > and it's completely controlled by KWin.
> > 
> > How do you know its wl_surface?
> > 
> > Would be better to move lock/unlock to a separate .xml file and have
> > ksmserver handle that imho.
> > kwin or any other compositor would recognize the surface by its role then.
> 
> I had thought about it over the weekend how it could work:
> *) ksld gets split into an own library
> *) kwin uses this ksld library
> *) ksld gets extended so that we can provide additional arguments to be
> passed to the greeter
> *) we pass the fd or socket name to the greeter
> *) any wl_surface coming over this fd with the greeter's pid is a lock
> screen surface
> (maybe only providing the fullscreen protocol for this socket)

Feel like you are reinventing libwayland here.

> What's important to me is to have the lock screen absolutely secure and that
> includes that in KWin I do not want to trust any other process and
> especially want to have the basics around screen locking inside KWin and
> being controlled by KWin. As soon as the screen is supposed to be locked,
> the input processing must stop, no matter whether the greeter is ready or
> not. If we leave it in ksmserver there will always be a timing vector and
> also the problem of knowing when to unlock - attacking the greeter should
> not result in chances to unlock the screen.

The lock/unlock protocols serves exactly this purpose, here's a verbose 
description of how it works:

*) ksmserver is a Wayland client that binds kf5_shell
*) ksmserver is asked to lock (via loginctl, plasmoid or context menu)
*) ksmserver calls the kf5_shell.lock request
*) kwin hides all surfaces, prevent input and maybe turn the screen off, this 
is all independent from the greeter being running or not
*) kwin emits the prepare_lock_surfaces and ksmserver picks it up
*) ksmserver runs the greeter which will create the surfaces
*) ksld use set_surface_role to set the lock role on those surfaces
*) kwin set lock surfaces position on its layer
*) Keyboard, touch or mouse input happens and the screen is turned on
*) User authenticates and ksld calls unlock
*) kwin resumes the desktop and ksld destroys the surfaces

Note that lock/unlock requests can be moved to a dedicated interface.

> > > * add_trusted_client: I kind of don't understand how that's supposed to
> > > work. Where's the fd coming from and how does the shell user know about
> > > it?
> > 
> > It's the fd of a socket to the Wayland server open by the client that
> > need to be trusted.
> > 
> > This comes from Weston having the screenshooter interface and a screenshot
> > tool. The idea was to forbid clients not in the whitelist to use that
> > interface and thus avoid malicious programs to capture your screen.
> > A shell would open the screenshooter program when it needs to do a
> > screenshot and add it to the whitelist.
> > 
> > This can probably go away although I don't know how ksnapshot will
> > work on Wayland.
> 
> ah well - I know there was a discussion about handling such clients. Not to
> myself: read those mails ;-) In general I'm not a fan of whitelists as that
> makes everything just more complex - we allow ksnapshot, but what about
> krita?

Krita should ask the shell to make a screenshot, the shell then executes a 
trusted program. Now I wonder what makes ksnapshot so special, the path?

It's better if we wait until the Wayland people come up with a better 
mechanism.

> My suggestion would be to keep that as a questionmark till the XDC where I
> could get some briefing by the people working on it ;-)

OK mean time I commented the request.