[Webkit-unassigned] [Bug 140131] New: [GStreamer] Move plugin scanner out of process when seccomp filters are enabled

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=140131

            Bug ID: 140131
           Summary: [GStreamer] Move plugin scanner out of process when
                    seccomp filters are enabled
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at igalia.com

We currently run plugin scanning in-process if seccomp filters are enabled, rather than use gst-plugin-scanner, so that it doesn't receive SIGSYS and dump core. See bug #140069. But this has disadvantages:

"Note that putting the plugin scanning in-process has two huge disadvantages though. You will dlopen() all (changed) plugins, which in turn loads all dependent libraries... and they will never be unloaded again for this process. And if any plugin crashes during initialization, it will just take your application process with it."

I see three options:

* Live with it. Presumably, plugins won't be changed very often, and only a modified plugin should be dlopened() by the plugin scanner (right?).
* Try to run the plugin scanner before initializing seccomp filters. We'd have to initialize gstreamer in WebKit2 instead of WebCore, even in web processes that never use gstreamer. Yuck.
* Rewrite the sandbox so that it's based on ptrace() rather than SIGSYS. (I haven't researched ptrace() fully. I think it would suffice, but I'm not sure what the disadvantages would be.) This would require rewriting the sandbox from scratch. It's probably not worth it for just gst-plugin-scanner, but perhaps another dependency will try to run a subprocess in the future.

I intend to at least explore option #3.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150106/f0442c48/attachment-0002.html>