[PATCH] Add layer-shell-unstable-v1.xml

[Drew DeVault]

On 2018-05-08  2:24 PM, Daniel Stone wrote:
> Unless I'm missing something, taskbars need a separate protocol to
> communicate the task list, tell the compositor to raise/activate the
> surfaces for that task, etc. I guess lock screens would be handled by
> the 'overlay' mode, though that makes me incredibly itchy for the
> security implications of having a lock state the compositor is unaware
> of.

Depends on the taskbar. We expect to be working with KDE in the future
to draw up protocols for this as well, though. Also, we have a separate
protocol coming down the line later for helping lock screens out:

https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-input-inhibitor-unstable-v1.xml

Feel free to take an early look, but let's keep the discussion focused
on layer-shell instead of picking this protocol apart too.

> This discussion mentions (amongst quite a lot of other things, some
> fairly unpleasant) that access to layer-shell _must_ be locked down to
> trusted clients only, which everyone takes as a given. That really
> seems like it's worth mentioning in the introduction, though it
> contradicts the 'broad number of other applications' line.

We have some nebulous plans for opening up "locked down" protocols to
third parties in a secure way in the future. Again, taking the
discussion in this direction could get out of scope for layer-shell
pretty quick. Maybe we need to shelve this and discuss how to provide
secure access to privledged protocols to third-parties first, but we're
confident that the ideas we're thinking about will work (they're mostly
building on top of what Weston already does to seucre its desktop
shell).

I agree that the discussion on earlier versions of the protocol brought
up some unpleasant consequences of the early design decisions. However,
we redesigned those parts until we got what we believe is a pretty solid
protocol.

> From a purely Weston point of view, I'm not at all sure how we'd go
> about authenticating arbitrary (from the compositor's point of view,
> i.e. not launched in a trusted way?) third-party clients, so don't
> know how we'd go about implementing this in that compositor. Ideas
> welcome, of course.

Just to give a quick overview of what we have in mind, we start by
opening the socket ourselves and noting that the wl_client has some set
of permissions, then we fork from the compositor and use WAYLAND_SOCKET
instead of WAYLAND_DISPLAY for the client connection. Weston does
something like this at compositor/main.c:weston_client_launch.

On top of this we want to build some simple protocols subprocesses can
use to grant a subset of their permissions to their own children. This
would probably be as simple as a list of interface names they're allowed
to bind to. The compositor could combine this knowledge with global
filtering to clean up the loose ends.

These ideas are still somewhat nebulous but I'm confident enough that
it'll work that I think we can proceed with the discussion on protocols
like layer-shell. Compositors which are interested in implementing these
protocols and securing them today can do something simple like
weston_client_launch as a temporary solution and make it more accessible
to third parties later.

> This was an interesting read. From a high level though, there's a fair
> bit of overlap with the IVI shell, which also exposes the same concept
> of stacked layers (and surface attachment to layers), out to clients.
> Historically ivi-shell has also included its own wl_shell/xdg_shell
> alternative for apps, but Michael Tayfel's recent patchset (which I
> think is a good thing) deprecates that by letting the IVI shell expose
> xdg-shell to clients.
> 
> Maybe there could be a good future in merging this with a rationalised
> IVI shell?

I think it might be possible to replace IVI shell with layer shell (or
replace a subset of IVI shell with layer shell), but I'm not sure that
the other way around is a great plan. I also find it highly questionable
to repurpose xdg-shell in places like IVI (e.g. in a non-desktop
setting); I think it's far better to define new shells.

For some context, in wlroots we're already accustomed to the idea of
several distinct shells. We used to have a Grand Unified Shell
Abstraction when we were based on wlc, but learned our lesson and moved
to a new approach. Today, we have a "view" abstraction, but it's rather
thin and not all shell surfaces are views. For example, Xwayland
unmanaged surfaces are supported, but do not participate in the view
abstraction. Layer surfaces also do not participate in the view
abstraction. And even for those who do use the view abstraction, it's a
very thin abstraction, and consumers of views are exposed to
shell-specific concerns. This is more work, but allows us to have _much_
better support for each shell.

In short, we think that embracing the differences between shells is a
better design than attempting to fit a square peg in a variety of holes.

--
Drew DeVault