Bug 258403
| Summary: | [GLib] Expose more GStreamer paths in sandbox | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Philippe Normand <philn> |
| Component: | WPE WebKit | Assignee: | Philippe Normand <philn> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Philippe Normand
Not sure why, I don't have this issue with GTK builds...
With local deps build of GStreamer, the gst plugin scanner is unable to update the registry, just keeps spewing warnings like this:
Could not open log file '/home/phil/tmp/gst.log' for writing: No such file or directory
Could not open log file '/home/phil/tmp/gst.log' for writing: No such file or directory
0:00:00.001719713 19 0x242eef0 WARN GST_PLUGIN_LOADING gstplugin.c:491:gst_plugin_register_func: plugin "/var/home/phil/WebKit/WebKitBuild/deps-build/subprojects/gstreamer-full/subprojects/gstreamer/p
lugins/elements/libgstcoreelements.so" has incompatible version (plugin: 1.23, gst: 1.22), not loading
...
And also where can I write files now? home seems readonly :(
Setting WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 works around the bug.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
There's no way BubblewrapLauncher could plausibly be expected to know that you've installed GStreamer inside the WebKit build directory and it needs to mount the build directory in the sandbox. I assume this deps-build was never tested with the sandbox enabled until now?
You can review bindGStreamerData in BubblewrapLauncher.cpp to see how it decides to mount particular locations.
(In reply to Philippe Normand from comment #0)
> And also where can I write files now? home seems readonly :(
It would not be useful for it to be writable, because it's not the same home as on your host system and you'd be writing to the abyss. Many directories *within* home are mounted from the host, though, e.g., ~/.local/share/gstreamer-1.0. So if you're just debugging, you this is one of various places you can write stuff to. (Corollary: the data in these directories is expected to be malicious, because the compromised web process can write to them.)
Michael Catanzaro
This local deps build of GStreamer, is it specific to GStreamer? Not something we do with other dependencies?
I think it's OK to go a little crazy with mounting build directory locations, but we'd need to pass that along via some preprocessor define, and restrict it to ENABLE(DEVELOPER_MODE).
Philippe Normand
(In reply to Michael Catanzaro from comment #1)
> There's no way BubblewrapLauncher could plausibly be expected to know that
> you've installed GStreamer inside the WebKit build directory and it needs to
> mount the build directory in the sandbox. I assume this deps-build was never
> tested with the sandbox enabled until now?
>
It was, but on a different setup (flatpak SDK). I forgot to mention I'm trying this now from a Toolbx running a F38 container...
Philippe Normand
(In reply to Michael Catanzaro from comment #2)
> This local deps build of GStreamer, is it specific to GStreamer? Not
> something we do with other dependencies?
>
I'm using it for GStreamer, but in the end it's just a meson project aggregating whatever other meson projects you want. See Tools/flatpak/local-projects/meson.build
> I think it's OK to go a little crazy with mounting build directory
> locations, but we'd need to pass that along via some preprocessor define,
> and restrict it to ENABLE(DEVELOPER_MODE).
OK, I can try something in that direction.
Philippe Normand
Pull request: https://github.com/WebKit/WebKit/pull/15444
EWS
Committed 265773@main (47a42208eb06): <https://commits.webkit.org/265773@main>
Reviewed commits have been landed. Closing PR #15444 and removing active labels.