cross-client surface references
daniel at fooishbar.org
Thu Jul 9 02:00:56 PDT 2015
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?',
>> 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.
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.
More information about the wayland-devel