cross-client surface references

[Alexander Larsson]

On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> Hi,

> 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?', 
> and
> 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 
> few
> 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.