[Webkit-unassigned] [Bug 188568] [GTK][WPE] Implement subprocess sandboxing

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188568

--- Comment #67 from Michael Catanzaro <mcatanzaro at igalia.com> ---
BTW the set_sandbox_enabled() API parallels all the other functions of WebKitWebContext that must be called before the web process is started, and none of those are properties, so I don't think there's any need to add a construct-only sandbox-enabled property: I would just add the new setter function.

(In reply to Carlos Garcia Campos from comment #64)
> Comment on attachment 349888 [details]
> [GTK][WPE] Implement subprocess sandboxing
> 
> Also noticed that this patch is adding new API without a test. I guess it's
> not easy to test this with a unit test?

The test will be disabled on the bots anyway, since it can't run in flatpak. That's the big flaw in this plan. We can't test anything under the sandbox if we're switching the infrastructure to flatpak.

> In any case, I think it would be a
> good idea to add a --enable-sandbox (or similar) to MiniBrowser to manually
> test this.

We could add it to minibrowser, but remember it won't work via run-minibrowser, because that will use flatpak. The envvar might be enough for MiniBrowser.

(In reply to Patrick Griffis from comment #61)
> Ok so it looks like Flatpak ties the lifetime of the proxy to a pipe between
> the processes, that would remove relying on destructors and just be more
> reliable in general.
> 
> I'm not sure the cleanest way to tie that to the processpool though.

It doesn't need to be tied to the process pool. Just make sure it doesn't linger after the UI process quits.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180920/efc6a41e/attachment.html>