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

[bugzilla-daemon at webkit.org]

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

--- Comment #74 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #67)
> 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.

Most of those functions where added when we only had the default context (it's not possible to create the default web context explicitly). I agree we need the setter if we want to allow sandboxing on the default web context.

> (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/20180922/310ab82b/attachment.html>