cross-client surface references

[Daniel Stone]

Hi Alex,

On 9 July 2015 at 09:44, Alexander Larsson <alexl at redhat.com> wrote:
> On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
>> 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.

Fair enough; that does help.

Is that the absolute limit of what you require: that the higher-priv
dialog must be a child of the lower-priv window, and that's it?
Without an interface that was very strictly limited to that exact
usecase, I can see no end of issues for manipulation.

Even with that, I'm struggling to think of how to do it in a truly
secure fashion. My base idea would be for the lower-priv client to
create an fd referring to its xdg_surface, which when passed to the
higher-priv client (having its own separately-initiated connection to
the compositor), allowed it to use a special interface to create a
modal dialog as a child of that surface, and nothing else. But the
wider we drag the surface area, the more difficult it gets to design
out really unpleasant races.

Cheers,
Daniel