[Webkit-unassigned] [Bug 193571] [GTK][WPE] Add API to add paths to sandbox

[bugzilla-daemon at webkit.org]

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

--- Comment #42 from youenn fablet <youennf at gmail.com> ---
> As long as WebExtensions exist which run arbitrary user provided code inside
> the sandbox applications will want to add custom paths to the sandbox for
> various functionality. A simple example is Epiphany stores adblock data that
> the web process has to read. This data does not fall under any normal WebKit
> directories.

In that particular case, the UIProcess could open this adblock data file and pass the file handle to the WebProcess. The WebProcess could then read the content (or if not feasible, the content would be sent through IPC either raw or processed).

Given JavaScript is run in WebProcess, I am not sure it is safe for arbitrary user provided code to run in it and provide priviledges to enable it to run.

(In reply to Michael Catanzaro from comment #39)
> (In reply to youenn fablet from comment #32) 
> > That leads to the question whether this API is a temporary solution to ease
> > migrating apps to being sandboxed or if it will have more permanent usage.
> 
> It's permanent. Currently our sandbox strictly limits the paths that are
> allowed: anything under the standard XDG data dirs/prgname, e.g.:
> 
> ~/.cache/epiphany
> ~/.config/epiphany
> ~/.local/share/epiphany
> 
> which is simultaneously too restrictive AND too permissive. E.g. in Epiphany
> we need to be able to whitelist temporary profiles under /tmp, which look
> like:
> 
> /tmp/epiphany-mcatanzaro-fPO5Qw

Another approach would be to make WebKit aware of these code paths.
Something like, please use "/tmp/epiphany-mcatanzaro-fPO5Qw" as temporary folder for that browsing session.
Then, WebKit would whitelist this folder at process launch time.
As an added bonus, WebKit could for instance monitor the size of "/tmp/epiphany-mcatanzaro-fPO5Qw", clear the folder when appropriate...

-- 
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/20190125/7cc1424b/attachment.html>