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

[bugzilla-daemon at webkit.org]

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

--- Comment #91 from youenn fablet <youennf at gmail.com> ---
Comment on attachment 351370
  --> https://bugs.webkit.org/attachment.cgi?id=351370
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=351370&action=review

> Source/WebKit/UIProcess/glib/NetworkProcessProxyGLib.cpp:33
> +    WebsiteDataStore& store = processPool().websiteDataStore()->websiteDataStore();

s/WebsiteDataStore/auto/ or remove the local variable since it is used only once.

> Source/WebKit/UIProcess/glib/NetworkProcessProxyGLib.cpp:34
> +    store.resolveDirectoriesIfNecessary();

Not sure this call is needed either.

> Source/WebKit/UIProcess/glib/StorageProcessProxyGLib.cpp:31
> +void StorageProcessProxy::platformGetLaunchOptions(ProcessLauncher::LaunchOptions& launchOptions)

StorageProcess is now gone so no need to handle that.
Instead, store.resolvedIndexedDatabaseDirectory and store.resolvedServiceWorkerRegistrationDirectory should be passed to NetworkProcessProxy.

> Source/WebKit/UIProcess/glib/StorageProcessProxyGLib.cpp:39
> +    launchOptions.extraSandboxPaths.append(store.resolvedServiceWorkerRegistrationDirectory());

extraSandboxPaths does not really state that this is for read/write access to the filesystem.
It would be nice to make it clear here.
grantedReadWriteDirectories maybe?

The alternative would be to use extraInitializationData this way:
extraInitializationData.add("indexedDatabaseDirectory"_s, store.resolvedIndexedDatabaseDirectory());
extraInitializationData.add("localStorageDirectory"_s, store.resolvedLocalStorageDirectory());
I slightly prefer this approach :) compared to a GTK specific Vector<String>.

> Source/WebKit/UIProcess/glib/WebProcessProxyGLib.cpp:44
> +    websiteDataStore().resolveDirectoriesIfNecessary();

Is resolveDirectoriesIfNecessary call needed? Shouldn't already be done by WebProcessPool?

-- 
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/20181003/afae1019/attachment.html>