Bug 268759 – [GStreamer] BubblewrapLauncher sandbox lacks directory for the gstreamer user registry cache directory

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Pujos]

Version: WebKitGTK 2.42.4 on openSUSE Tumbleweed.

If a web page running in a Bubblewrap sandbox (BubblewrapLauncher.cpp)
initializes gstreamer, gstreamer cannot load the user's config plugin:

For example loading cnn.com which has an autoplay video:

GST_DEBUG=GST_REGISTRY:6,GST_PLUGIN_LOADING:4 MiniBrowser https://cnn.com

...
0:00:00.000519909     2 0x55ca781e8b00 INFO            GST_REGISTRY gstregistry.c:1836:ensure_current_registry: reading registry cache: /home/bobbie/.cache/gstreamer-1.0/registry.x86_64.bin
0:00:00.000541136     2 0x55ca781e8b00 INFO            GST_REGISTRY gstregistrybinary.c:601:priv_gst_registry_binary_read_cache: Unable to mmap file /home/bobbie/.cache/gstreamer-1.0/registry.x86_64.bi
n : Failed to open file “/home/bobbie/.cache/gstreamer-1.0/registry.x86_64.bin”: open() failed: No such file or directory
0:00:00.000549480     2 0x55ca781e8b00 INFO            GST_REGISTRY gstregistrybinary.c:611:priv_gst_registry_binary_read_cache: Unable to read file /home/bobbie/.cache/gstreamer-1.0/registry.x86_64.bi
n : Failed to open file “/home/bobbie/.cache/gstreamer-1.0/registry.x86_64.bin”: No such file or directory
0:00:00.000552260     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1864:ensure_current_registry: Updating registry cache
0:00:00.000554436     2 0x55ca781e8b00 INFO            GST_REGISTRY gstregistry.c:1703:scan_and_update_registry: Validating plugins from registry cache: /home/bobbie/.cache/gstreamer-1.0/registry.x86_6
4.bin
0:00:00.000556363     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1713:scan_and_update_registry: scanning paths added via --gst-plugin-path
0:00:00.000558204     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1736:scan_and_update_registry: GST_PLUGIN_PATH not set
0:00:00.000560033     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1748:scan_and_update_registry: GST_PLUGIN_SYSTEM_PATH not set
0:00:00.000562199     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1755:scan_and_update_registry: scanning home plugins /home/bobbie/.local/share/gstreamer-1.0/plugins
0:00:00.000564062     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1416:gst_registry_scan_path_internal:<registry0> scanning path /home/bobbie/.local/share/gstreamer-1.0/plugins
0:00:00.000571389     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1419:gst_registry_scan_path_internal:<registry0> registry changed in path /home/bobbie/.local/share/gstreamer-1.0/plugi
ns: 0
0:00:00.000573231     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1609:priv_gst_get_relocated_libgstreamer: attempting to retrieve libgstreamer-1.0 location using dladdr()
0:00:00.000588168     2 0x55ca781e8b00 LOG             GST_REGISTRY gstregistry.c:1613:priv_gst_get_relocated_libgstreamer: dli_fname: /lib64/libgstreamer-1.0.so.0
0:00:00.000590622     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1763:scan_and_update_registry: found libgstreamer-1.0 library at /lib64
0:00:00.000592582     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1771:scan_and_update_registry: using plugin dir /lib64/gstreamer-1.0
0:00:00.000594316     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1416:gst_registry_scan_path_internal:<registry0> scanning path /lib64/gstreamer-1.0
0:00:00.000644381     2 0x55ca781e8b00 LOG             GST_REGISTRY gstregistry.c:1335:gst_registry_scan_path_level:<registry0> file /lib64/gstreamer-1.0/libgstcoreelements.so looks like a possible mod
ule
0:00:00.000646947     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1396:gst_registry_scan_path_level:<registry0> file /lib64/gstreamer-1.0/libgstcoreelements.so not yet in registry
0:00:00.000648920     2 0x55ca781e8b00 DEBUG           GST_REGISTRY gstregistry.c:1165:gst_registry_scan_plugin_file: Starting plugin scanner for file /lib64/gstreamer-1.0/libgstcoreelements.so
...

////////

Here the user is 'bobbie' and gstreamer fails to load file /home/bobbie/.cache/gstreamer-1.0/registry.x86_64.bin because 
the sandbox is missing access to ~/.cache/gstreamer-1.0/

This result in an unnecessary scan of the registry with gst-plugin-scanner.

This issue does not happen when disabling the sandbox (WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1) as the cache folder is accessible.

The gstreamer user cache folder should probably be added in bindGStreamerData() in BubblewrapLauncher.cpp.

[Michael Catanzaro]

Huh, I guess we could give it read-only access?

Presumably allowing the web process to write to the cache would be a sandbox escape, so we should not do that?

[Michael Pujos]

Read access is a good start.

But gstreamer may want to write  the ~/.cache/gstreamer-1.0/registry.x86_64.bin file (for example it it does not exist or to update it).

If it cannot write the file, only an unsandboxed program making use gstreamer (could be anything, like gst-inspect-1.0) will be able to create/update it, which might be OK if giving write access to the sandbox is too problematic.

[Philippe Normand]

Write access should be granted yes. I thought it was already the case.

Do you want to send a PR? Otherwise I can take a look.

[Philippe Normand]

Might be worth setting a custom path for the registry in the sandbox, then setting GST_REGISTRY_PATH env var in WebProcess.

[Michael Pujos]

I have never contributed to WebKit and just looked at the relevant code while researching this issue, so it is probably best that you have a go at it.

There is also a second issue related to this one for which I'm writing a detailed separate issue at the moment: the failure to run gst-plugin-scanner due to the sandbox. Even if this issue is fixed, the new one must be fixed for the scanner to work.

[Michael Catanzaro]

(In reply to Philippe Normand from comment #3)
> Write access should be granted yes. I thought it was already the case.
> 
> Do you want to send a PR? Otherwise I can take a look.

If you grant write access, then GStreamer needs to be prepared for registry.x86_64.bin to be malicious, as it could have been written by a compromised web process. Is it ready for that?

(In reply to Philippe Normand from comment #4)
> Might be worth setting a custom path for the registry in the sandbox, then
> setting GST_REGISTRY_PATH env var in WebProcess.

For this to work, BubblewrapLauncher would also need to create that directory (which is easy).

One last thing to consider: if all subprocesses share the same registry, then they can presumably attack each other, unless GStreamer is prepared for the registry to be malicious. The sandbox is ideally supposed to block that too. But if the registry scanner is probably safe, then sharing is probably OK.

[Philippe Normand]

this one? https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2877

[Philippe Normand]

Michale, if GStreamer is initialized with a registry file that is invalid or not present, afaik, it will generate a registry in-memory, which will delay playback.

imho it's better to let the WebProcess generate a registry file the first time GStreamer is initialized, and follow-up initializations will benefit from it.

[Michael Pujos]

(In reply to Philippe Normand from comment #7)
> this one? https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2877

Yes exactly, this one. So not submitting a new issue for it.

It happens because on distros using UsrMerge, /lib64 is a symlink to /usr/lib64/ and the sandbox refuses to launch /lib64/../libexec/gstreamer-1.0/gst-plugin-scanner while it resolved to /usr/lib64/libexec/gstreamer-1.0/gst-plugin-scanner which is allowed.

In fact, that is originally this failure that bring me to report this issue.

[Philippe Normand]

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

[EWS]

Committed 274144@main (cafc9b17f1fa): <https://commits.webkit.org/274144@main>

Reviewed commits have been landed. Closing PR #23912 and removing active labels.

[Michael Pujos]

Excellent, thanks !

Any plan to address the failure to launch gst-plugin-scanner in hosts using UsrMerge ?

I think this issue is more of a WebKit sandbox issue rather than a gstreamer issue (where it has been reported).

Although with this registry user cache fix, gst-plugin-scanner would be rarely launched by the sandbox: only if the user registry cache file does not exist or if gstreamer thinks it must update it for some reason.

[Philippe Normand]

(In reply to Michael Pujos from comment #12)
> Excellent, thanks !
> 
> Any plan to address the failure to launch gst-plugin-scanner in hosts using
> UsrMerge ?
> 
> I think this issue is more of a WebKit sandbox issue rather than a gstreamer
> issue (where it has been reported).
> 

iirc the scanner path is hardcoded during the gst build so it's currently a GStreamer issue.

[Michael Pujos]

The scanner path is determined this way:

 priv_gst_get_relocated_libgstreamer () is called at this line:

https://github.com/GStreamer/gstreamer/blob/main/subprojects/gstreamer/gst/gstpluginloader.c#L482

If we look at that function:

https://github.com/GStreamer/gstreamer/blob/main/subprojects/gstreamer/gst/gstregistry.c#L1577


If dladdr() is available, it is used to determine the directory where the gstreamer lib is installed. On my openSUSE install, this function returns /lib64 (which is a symbolic link to /usr/lib64).

Then if you get back to the caller in gstregistry.c, it builds the full path in this section:

https://github.com/GStreamer/gstreamer/blob/main/subprojects/gstreamer/gst/gstpluginloader.c#L493

This results in /lib64/../libexec/gstreamer-1.0/gst-plugin-scanner, a path that is valid on the host (resolved to /usr/libexec/gstreamer-1.0/gst-plugin-scanner) but not in the sandbox.

Not sure how it can be addressed, either in the sandbox or gstreamer. I suppose if gstreamer normalized the path, it may work.

In any case a work-around is to start the process with GST_PLUGIN_SCANNER:

GST_PLUGIN_SCANNER=/usr/libexec/gstreamer-1.0/gst-plugin-scanner MiniBrowser https://cnn.com

But this should not be necessary (and isn't outside of the sandbox).

Maybe, in the sandbox code, if the GST_PLUGIN_SCANNER env variable is not set, it could be hardcoded to "/usr/libexec/gstreamer-1.0/gst-plugin-scanner", whose execution is allowed.

////////

Here's relevant trace for 'GST_DEBUG=GST_PLUGIN_LOADING:5 MiniBrowser https://cnn.com' showing the failure to exec the scanner (if you have the PR fixing this issue applied, remove ~/.cache/gstreamer-1.0 to force the scan):

0:00:00.000588646     2 0x557354f93af0 DEBUG     GST_PLUGIN_LOADING gstpluginloader.c:579:gst_plugin_loader_spawn: found libgstreamer-1.0 library at /lib64
0:00:00.000595383     2 0x557354f93af0 DEBUG     GST_PLUGIN_LOADING gstpluginloader.c:595:gst_plugin_loader_spawn: constructing path to system plugin scanner using plugin dir: 'lib64', plugin scanner dir: 'libexec'
0:00:00.000598487     2 0x557354f93af0 DEBUG     GST_PLUGIN_LOADING gstpluginloader.c:609:gst_plugin_loader_spawn: using system plugin scanner at /lib64/../libexec/gstreamer-1.0/gst-plugin-scanner-x86_64
0:00:00.007079738     2 0x557354f93af0 ERROR     GST_PLUGIN_LOADING gstpluginloader.c:442:gst_plugin_loader_try_helper: Spawning gst-plugin-scanner helper failed: Failed to execute child process “/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner” (No such file or directory)
0:00:00.007096635     2 0x557354f93af0 INFO      GST_PLUGIN_LOADING gstpluginloader.c:617:gst_plugin_loader_spawn: No gst-plugin-scanner available, or not working

(WebKitWebProcess:2): GStreamer-WARNING **: 17:40:24.345: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.

[Philippe Normand]

(In reply to Michael Pujos from comment #14)

> Maybe, in the sandbox code, if the GST_PLUGIN_SCANNER env variable is not
> set, it could be hardcoded to
> "/usr/libexec/gstreamer-1.0/gst-plugin-scanner", whose execution is allowed.

I don't think we can expect to have all sandboxed GStreamer apps duplicating this workaround in their code.

[Michael Pujos]

In my opinion, gstreamer should not have to care if it is running in a sandbox or not. Sandboxes should be transparent vs running the same software (or library) unsandboxed.