Bug 293696 – [GStreamer] Local video files are unexpectedly blocked by web process sandbox

• Status: NEW
• Component: Media

[Brandon]

Created attachment 475402 [details]
Error screenshot

Overview: Right clicking a local, non-embedded .mp4 (H.264/H.265 encoded) and choosing open-with Web (epiphany) results in a black screen with 'slashed play button' icon. This had been functioning properly as recently as 11/2024. Other media such as .pdf, .jpg open/render properly. Videos (totem) application is able to play same file successfully.

Steps to reproduce:
1. Right- or context-click an .mp4 file, choose open-with Web

Actual result: Browser opens to black screen with 'slashed play button' icon.

Expected result: Video plays in MiniBrowser

Build date and hardware: 
5/28/2025 Fedora Linux 42 (Workstation)
Kernel 6.14.6-300.fc42.x86_64
GNOME v.48
epiphany-48.3-1.fc42.x86_64
webkitgtk6.0-2.48.2-1.fc42.x86_64
webkit2gtk4.1-2.48.2-1.fc42.x86_64
gst-inspect-1.0 version 1.26.1
GStreamer 1.26.1
gstreamer1-1.26.1-1.fc42.x86_64
gstreamer1-plugins-base-1.26.1-1.fc42.x86_64
gstreamer1-plugins-good-1.26.1-1.fc42.x86_64
gstreamer1-plugins-good-gtk-1.26.1-1.fc42.x86_64
gstreamer1-plugins-bad-free-libs-1.26.1-1.fc42.x86_64
gstreamer1-plugins-good-qt-1.26.1-1.fc42.x86_64
gstreamer1-plugins-good-qt6-1.26.1-1.fc42.x86_64
gstreamer1-plugin-openh264-1.26.1-1.fc42.x86_64
gstreamer1-plugins-ugly-free-1.26.1-1.fc42.x86_64
gstreamer1-plugin-gtk4-0.13.6-1.fc42.x86_64
gstreamer1-plugins-ugly-1.26.1-1.fc42.x86_64
gstreamer1-plugins-bad-freeworld-1.26.1-1.fc42.x86_64
gstreamer1-plugin-libav-1.26.1-1.fc42.x86_64
gstreamer1-plugins-bad-free-1.26.1-1.fc42.x86_64

Additional builds and platforms:
Able to reproduce on Fedora 38, 40, 41, 42 with current packages. Not able to reproduce on MacOS Sequoia 15.5/Safari, functionality is working as expected. 

Additional information:
From journalctl log:
May 28 10:29:39 bb-fedora WebKitWebProces[5007]: Failed to read portal settings: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Portal operation not allowed: Could not to open '/proc/pid/4826': No such file or directory

From web inspector console:
[Error] Failed to load resource: Plug-in handled load (farm_200.mp4, line 0)

Reported to GNOME issue tracker: https://gitlab.gnome.org/GNOME/epiphany/-/issues/2654

[Philippe Normand]

I don't see how that could ever work, maybe you had the WebProcess sandbox disabled, because that's the only way it can work.

With sandbox enabled, GStreamer fails to read the file because it doesn't have access (even if the file is in xdg-downloads).

[Brandon]

Updated description to the reference to MiniBrowser. I'm a sysadmin, so I didn't realize that MiniBrowser was a separate debug tool. Issue is occurring in the standard Web browser, but doesn't occur in MiniBrowser, if that info helps. I also tested with WebProcess sandbox disabled and it didn't work (logs attached). Basically every other browser on every other platform can play a .mp4 file directly in the browser (non-embedded), so I would consider it general functionality.

[Brandon]

Created attachment 475414 [details]
MiniBrowser test

[Brandon]

Created attachment 475415 [details]
No sandbox debug log

[Philippe Normand]

How did you disable the sandbox? 

filesrc gstfilesrc.c:585:gst_file_src_start:<source> error: No such file "/home/bb/Downloads/farm_200.mp4"

[Brandon]

(In reply to Philippe Normand from comment #5)
> How did you disable the sandbox? 
> 
> filesrc gstfilesrc.c:585:gst_file_src_start:<source> error: No such file
> "/home/bb/Downloads/farm_200.mp4"

I just tried running with 'WEBKIT_DISABLE_SANDBOX=1 epiphany file///test.mp4'

[Philippe Normand]

Try with WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead.

[Brandon]

(In reply to Philippe Normand from comment #7)
> Try with WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead.

I thought you were joking, but that worked - I really appreciate the workaround! I'm going to set a bash variable and call it a day. This is an air-gapped system used for digital signage, so no real risk. I'd love to see the functionality supported (works on Safari), but the client will be happy with any solution.

[Brandon]

(In reply to Philippe Normand from comment #7)
> Try with WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 instead.

I thought you were joking, but that worked - I really appreciate the workaround! I'm going to set a bash variable and call it a day. This is an air-gapped system used for digital signage, so no real risk. I'd love to see the functionality supported (works on Safari), but the client will be happy with any solution.

[Michael Catanzaro]

Hmm, the web process sandbox is not supposed to prevent main resource loads of file:/// URLs. Surely the file is supposed to be read by the network process, which is not sandboxed.

[Philippe Normand]

Why would a local filesystem path go through the network process?

Anyway, this is a niche case, if someone wants to write a custom filesrc element doing that kind of plumbing, feel free to do so, but we have more important things to work on imho.

[Michael Catanzaro]

(In reply to Philippe Normand from comment #11)
> Why would a local filesystem path go through the network process?

The network process manages content loading, local data storage, and also anything else that we don't want to put into the UI process or the web process for whatever reason. I'm a little surprised that any new GStreamer element is required for videos to work. Notably, if running outside Flatpak, you can browse your entire filesystem using file:/// URLs without disabling the bubblewrap sandbox; try it by navigating to file:///. Web pages and compromised web processes do not have access to your filesystem, but the network process does.

(Browsing the filesystem does not work under Flatpak, but file forwarding should still work, and that should be enough to play a video. But anyway, clearly this bug report is for the non-Flatpak case.)

[Michael Catanzaro]

Another example to test: opening an image file instead of a video works perfectly fine

(I don't disagree that you have many other important things to work on. Just saying sandbox is not expected to block this.)

[Michael Catanzaro]

(In reply to Philippe Normand from comment #11)
> Anyway, this is a niche case, if someone wants to write a custom filesrc
> element doing that kind of plumbing, feel free to do so, but we have more
> important things to work on imho.

(Um, if anybody *does* attempt to work on this: of course make sure the web process is not able to read arbitrary content from the filesystem.)

[Philippe Normand]

I see, I had no idea the network process can load file:// uris!

So this shouldn't be too hard to fix, we can use the httpsrc element.

[Philippe Normand]

Pull request: https://github.com/WebKit/WebKit/pull/46115