Bug 202071 - [GTK] Cannot perform most local loads with sandbox enabled
Summary: [GTK] Cannot perform most local loads with sandbox enabled
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Michael Catanzaro
URL:
Keywords:
Depends on:
Blocks: 206533
  Show dependency treegraph
 
Reported: 2019-09-20 20:52 PDT by Wayne BLaszczyk
Modified: 2020-02-05 10:06 PST (History)
7 users (show)

See Also:


Attachments
Patch (2.13 KB, patch)
2020-01-30 16:37 PST, Michael Catanzaro
no flags Details | Formatted Diff | Diff
Patch (2.16 KB, patch)
2020-01-30 16:40 PST, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Wayne BLaszczyk 2019-09-20 20:52:25 PDT
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.
Comment 1 Michael Catanzaro 2020-01-30 16:37:26 PST
Created attachment 389302 [details]
Patch
Comment 2 Michael Catanzaro 2020-01-30 16:40:27 PST
Created attachment 389303 [details]
Patch
Comment 3 Michael Catanzaro 2020-01-30 16:41:15 PST
Sorry for the long delay. :(

The problem was an old security check that's incompatible with our sandbox.
Comment 4 Carlos Garcia Campos 2020-01-31 00:18:48 PST
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?
Comment 5 Michael Catanzaro 2020-01-31 05:48:53 PST
(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.
Comment 6 Michael Catanzaro 2020-02-04 11:42:10 PST
Ping :)
Comment 7 Carlos Garcia Campos 2020-02-05 00:40:23 PST
Comment on attachment 389303 [details]
Patch

Ok, let's do this for now
Comment 8 WebKit Commit Bot 2020-02-05 10:06:07 PST
Comment on attachment 389303 [details]
Patch

Clearing flags on attachment: 389303

Committed r255824: <https://trac.webkit.org/changeset/255824>
Comment 9 WebKit Commit Bot 2020-02-05 10:06:08 PST
All reviewed patches have been landed.  Closing bug.