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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
