cross-client surface references
alexl at redhat.com
Thu Jul 9 01:44:48 PDT 2015
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> None of them will really work.
> This thread has sadly degenerated into: 'what if Wayland's object
> model was totally different? what if some of its explicit core design
> principles were thrown out the window?'. Realistically, that is not
> something that will happen in the Wayland 1.x timeframe, if ever.
> Where this thread started was, 'what's a good sandboxing model for
> clients which must be explicitly separated for security reasons?',
> the answer to that is the same answer to the same issue within WebKit
> 2 (UI process distrusts render processes), which is that your more
> trusted client itself becomes a Wayland compositor. Which is exactly
> what Jasper did with Wakefield, almost exactly for this usecase, a
> months ago. If there are issues with that design, then great, let's
> chase that up.
I'm not at all interested in the change that bill is talking about, and
I think it is unfortunate that it takes this thread off-topic, but this
is a mischaracterization of the problem.
Yes, using a subcompositor is a good idea for the case where a more
privileged process needs to contain some subclient. In fact, I took
Jaspers wakefield work and extended it for use in the case of e.g.
embedding a file previewer out of process.
However, the problem I have now is different, in that it involves an
existing, less privileged client initiating a higher privileged
operation (in a controlled fashion) and the higher privileged client
needing to refer to the lower privileged one. In particular, I need the
compositor to get toplevel parenting right (higher priv dialog has a
parent that is a lower priv toplevel).
This case can not really be solved using subcompositors.
More information about the wayland-devel