cross-client surface references

[Alexander Larsson]

On Thu, 2015-07-09 at 10:00 +0100, Daniel Stone wrote:

> > 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.
> 

I don't have a full implementation of this, but the usecase is to be
able to support "portals" out of the sandbox. For instance, one such
portal would be the "file/content chooser". The sandboxed app would
activate (via a filtered session bus) that the user select some file,
and then the portal would do the user interaction, and return the final
selected data.

In this case we need to be able to display the file chooser dialog (and
possibly other dialogs too if you want different kind of contents).
Such a dialog should at least be parented to the sandboxed app
toplevel, and possibly also modal (although that could be handled by
the app itself given a good enough portal api). I guess it may also be
useful for the portal to get told when the client toplevel was
unmapped.

Are there other things that could possibly be useful? I guess perhaps
one could imagine allowing the higher privileged process creating an
XdpPopup with the sandboxed app as parent. This would allow a right
-click on some selected text to bring up a menu with different sharing
options. This is a much more complex interaction though, and I'm not
sure if it can be made useful and safe.

> 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.
> 

You want a fd instead of a plain global identifier to make it
impossible to guess it from another client? There are some inherent
risks with passing fds around. For instance, you can block the
recipient forever by passing it a fuse fd which blocks forever in
close() (and close will be implicitly called if you don't read the fd
even!). Of course, once you have a dbus connection between the two
clients that can happen anyway.

Another approach would be to create an identifier for a particular
other client. That would require the higher privileged client to pass
some kind of client identifier to the lower priv client though, which
requires a more complex setup for doing the out-of-sandbox handover.