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