cross-client surface references

[Bill Spitzak]

On Fri, Jul 3, 2015 at 3:10 AM, Jonas Ådahl <jadahl at gmail.com> wrote:

>
> > This would work, but it still feels wrong to me. It has the same
> > priority-inversion as before (the less privileged clients gets to see
> > the more privileged one). It also limits what the "open file dialog"
> > client can do. For instance it can't open two (consecutive) surfaces
> > both with the other surface as the parent.
> > I think the sandboxed app should create a xdg_foreign for *its*
> > toplevel, and then the "open file dialog" should be able to use this as
> > a parent for its xdg_surfaces.
>
> With "see" I suppose you mean "be aware and map", because it wouldn't
> see the content.
>
> For the record, the original foreign surface idea was about putting less
> privileged clients's surfaces inside a more privileged client's parent
> surface, which indeed is quite the opposite of whats the intention here.
>
> But yes, that sounds like it should work as well, and would be less
> complex regarding mapping multiple windows.
>
> For this to be allowed, we'd have to either put all of this inside
> xdg_shell, or introduce something like "xdg_shell compatible surface"
> that we can say is Ok to pass as surfaces to xdg_surface.set_parent,
> since it is now strictly limited to a xdg_surface, but that is a minor
> problem.
>

I feel like this has to be part of the basic Wayland protocol, and should
work for every object a client can create.

The client that gets a "key" must also use the correct interface and makes
a new objectId that is exactly the same thing. It is not an
"xdg_shell_compatible_surface", the object actually *is* an xdg_surface.

I think it is ok if the client getting the key can do *any* requests on the
resulting object. It is way too difficult to separate the requests a client
actually needs from dangerous ones.

I'm not sure what to do with events. It seems like errors and responses to
requests should only go to the client that made the request. But
destruction must go to all clients. And input events it is hard to say, I
would try just sending them to the first client, and see if anything more
complicated is needed.

Besides the above example (where the parent client passes the key for it's
main xdg_surface to the child, which recreates it so that it can use it to
set the parent of it's modal window), this could be used to pass things
like the screen shooter api only to clients that the shell trusts.

So just vaguely what I see as a low-level Wayland api:

- Ability to take an objectId and turn it into a "key". This can be done
with any objectId. I think it is ok that this requires a round trip for the
server to generate the key, because it seems like it is necessary to ensure
the key is only used after the server knows about it. The keys are random
numbers so they cannot be guessed.

- Ability to take a "key" and an interface and turn them into a new
objectId.

It looks like to deal with malicious clients trying to flood the tables
with keys, it should be a fatal protocol error to request more than one key
per object. However this means another safety measure, that a key can only
be used once, is not possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150706/c6df22a3/attachment.html>