|Summary:||[GTK] Cannot perform most local loads with sandbox enabled|
|Product:||WebKit||Reporter:||Wayne BLaszczyk <wblaszcz>|
|Component:||WebKitGTK||Assignee:||Michael Catanzaro <mcatanzaro>|
|Severity:||Normal||CC:||afranke, bugs-noreply, cgarcia, commit-queue, mcatanzaro, pgriffis, renodr|
|Bug Depends on:|
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 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
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.