On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote: > Hi, > None of them will really work. > > 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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
