Bug 202071 – [GTK] Cannot perform most local loads with sandbox enabled

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Wayne BLaszczyk]

When trying to view local files via Epiphany-3.34.0, clicking on most directories does nothing. i.e. does not display the contents of that directory.
I say most, as some directories do work.
.cache .local and .config from the home directory do work. I know it's not a permission issue of the directories as I can rename one of those three working directories into something else, and I can no longer traverse into that directory. e.g. mv .cache .cache.org
Of the non working directories, if I right click and select Open Link in New Tab, then that does open a new tab with the contents of the directory.
I can revert back to Epiphany-3.32.5 and the problem goes away.
The system I'm using is self built from source (based on LFS) with the latest GNOME 3.34 components.

See https://gitlab.gnome.org/GNOME/epiphany/issues/934

The issue goes away if WebKitGTK is built with a -DENABLE_BUBBLEWRAP_SANDBOX=OFF parameter which is not an ideal work around.

[Michael Catanzaro]

Created attachment 389302 [details]
Patch

[Michael Catanzaro]

Created attachment 389303 [details]
Patch

[Michael Catanzaro]

Sorry for the long delay. :(

The problem was an old security check that's incompatible with our sandbox.

[Carlos Garcia Campos]

Comment on attachment 389303 [details]
Patch

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

> Source/WebCore/page/SecurityOrigin.cpp:371
> -#if !PLATFORM(IOS_FAMILY)
> +#if !PLATFORM(IOS_FAMILY) && !ENABLE(BUBBLEWRAP_SANDBOX)

I guess we should disable this when the sandbox is enabled, not only when building with sandbox support, no?

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #4)
> I guess we should disable this when the sandbox is enabled, not only when
> building with sandbox support, no?

No, because there's no good way to check at this level if the sandbox is enabled or not. We could test if .flatpak-info exists on disk, but that's just bad design.

So if keeping the same-volume check is desired, someone (not me :) will need to reimplement it at the network process level. I'm not even sure if we ever implemented it for soup ports in the first place. I can see the curl bug to do so, bug #166780. The cross-platform bug is bug #158552, but I can't see that anymore. From there, you can navigate to the soup bug to check if we ever implemented it or whether we left the bug open for three years, just as likely.

[Michael Catanzaro]

Ping :)

[Carlos Garcia Campos]

Comment on attachment 389303 [details]
Patch

Ok, let's do this for now

[WebKit Commit Bot]

Comment on attachment 389303 [details]
Patch

Clearing flags on attachment: 389303

Committed r255824: <https://trac.webkit.org/changeset/255824>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.