cross-client surface references

[Jasper St. Pierre]

My issue with this is that you're tying two things together. You want
access to """a surface""", and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new protocol that does what we want.

We have a few requirements:

1. We want to be able to refer to another surface for the point of
establishing parent-child modal dialog relationships. This is
important for sandboxing work.

2. We want to be able to pass this reference to a parent into a
subprocess, and perhaps not necessarily over the Wayland protocol. For
instance, it might want to be passed through DBus, or passed through a
command-line argument or environment variable somehow.

Let's do this by adding a new protocol: sandboxed_surface_manager.

(I didn't want to give it the name "sandboxed_shell" -- "shell" is overrated)

Here's what we get:

   sandboxed_surface *
sandboxed_surface_manager.get_surface_reference(xdg_surface *surface);
   sandboxed_surface * sandboxed_surface_manager.get_surface_for_id(string id);
   string sandboxed_surface.serialize_to_id();
   void sandboxed_surface.set_as_a_child(xdg_surface *surface);

Calling sandboxed_surface.serialize_to_id(); gives you an ID you can
shove through some other system. That ID should be unguessable.
Calling sandboxed_surface_manager.get_surface_for_id(); retrieves that
surface and deletes the ID from the global namespace.

(If you want to, replace the global ID namespace with an fd -- I can't
think of any way of having a compositor create an fd for an object and
have it still be understood for as the same object after it's passed
through a few clients without kernel support, but perhaps there's some
eventfd trick I'm missing?)

The things you can do with a sandboxed_surface are very limited. You
can set a new surface as a child (we could, I suppose, extend
xdg_surface.set_parent to take this new sandboxed_surface object as
well). You could perhaps do other things as well.

But the idea here is that we stay in object space as much as possible,
and we don't have an arbitrary way of fetching an xdg_surface on the
other side of a pipe and dealing with the resulting synchronization
issues. That's just asking for danger-town-USA.

Basically, as krh once told me, "any time you think about using global
IDs in Wayland, it's probably a bad idea. Think in terms of objects
instead".

On Thu, Jul 9, 2015 at 1:44 AM, Alexander Larsson <alexl at redhat.com> wrote:
> 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.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper