We unfortunately have to break existing web extensions that perform filesystem operations if we want to sandbox the web process. We have a couple of options here: 1) Require the web extension to set up some form of IPC with the UI process to ask it to perform the syscall for it. This would be inconvenient for web extension authors, and it would be a hole in the sandbox: the UI process should not trust input from the sandbox web process. 2) Provide API to open holes in the sandbox, so the web process can open extra files as needed. E.g. ~/.config/epiphany/adblock Consider also that the API I add in this patch is on the WebKitWebContext. That's probably *not acceptable* if extensions are expected to be developed separately from web browsers, which I think we probably want to support. So this is just a proof of concept; probably the final API should be on the WebKitWebExtension itself. Lastly consider that a better sandbox would trap or block many more syscalls than we currently do. In particular, it'd be really nice to block the web process from accessing the network (if the network process is enabled) (but I think web sockets are currently implemented in the web process only). That would require more sophisticated API beyond that added in this patch, so that the web process would be allowed to e.g. connect to https://easylist-downloads.adblockplus.org/ -- though I definitely want any API we provide to be at a much higher level than system calls.
Created attachment 243962 [details] Patch
Another acceptable resolution for this bug, so long as we keep the sandbox relatively lenient (so that it only blocks suspect filesystem accesses), would be to define a directory (e.g. XDG_DATA_DIR/webkitgtk/web-extensions) that will be whitelisted for use by web extensions, and not add any new API. That would likely be preferable.