<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so" href="https://bugs.freedesktop.org/show_bug.cgi?id=107516#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so" href="https://bugs.freedesktop.org/show_bug.cgi?id=107516">bug 107516</a> from <a class="email" href="mailto:gcp@sjeng.org" title="Gian-Carlo Pascutto <gcp@sjeng.org>"> Gian-Carlo Pascutto</a> <pre>To clarify the underlying cause of this: >Earlier commit reworked our sysfs handling to use realpath. >Sadly that backfired since the Firefox sandboxing mechanism rejects >that. Despite the files/folders being in the allowed list, of the >sandboxing mechanism. The problem is that the underlying implementation of realpath() in libc will issue lstat calls on each of the path components. In Mesa's case, this will cause it to try to stat /sys, which is not on the list of allowed paths. This in turn causes the realpath() call to fail. If this failure isn't handled things broke. Firefox 62 and later will now specifically allow the stat call (only). >Oddly enough, the Chromium sandboxing doesn't complain about any of >this. I'm not sure how much of Chromium's GPU sandbox is enabled by default (on non-Chromebooks), but they literally just did the same fix as we did a few days ago: <a href="https://chromium.googlesource.com/chromium/src/+/8655d49f657d3878c937f1387b3d31fa66c8e76a%5E%21/content/gpu/gpu_sandbox_hook_linux.cc">https://chromium.googlesource.com/chromium/src/+/8655d49f657d3878c937f1387b3d31fa66c8e76a%5E%21/content/gpu/gpu_sandbox_hook_linux.cc</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>