On Thu, Jul 09, 2015 at 10:00:56AM +0100, Daniel Stone wrote: > Hi Alex, > > On 9 July 2015 at 09:44, Alexander Larsson <[email protected]> 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?', > >> 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. > > 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.
That is more or less what was the idea before the thread derailed. Something like: low-priv-client: xdg_surf = xdg_shell.get_xdg_surface fd = export(xdg_surf) * pass fd to high-priv-client via dbus * high-priv-client: * receive fd from low-priv-client via dbus * xdg_foreign = import(fd) xdg_surf = xdg_shell.get_xdg_surface xdg_surf.set_parent(xdg_foreign) I think that if we clarify what happens if the exported surfaces disappears (which is the race you are referring to I suppose), as well as provide events for that on xdg_foreign so the high-priv-client can clean up etc, I don't see anything obvious that will go wrong. Also if we force the set_parent(foreign) to always stack above the foreign tree (similar to how subsurfaces stacking works), what would the security implications be? We can't put too many rescriptions on the xdg_surf of the high-priv-client, since it needs to be able to map its own child surfaces (popup menus and subsurfaces at least). Jonas _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
