Summary: | [GStreamer] Disable gst-plugin-scanner if seccomp filters are enabled | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||
Component: | WebCore Misc. | Assignee: | Michael Catanzaro <mcatanzaro> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | cgarcia, commit-queue, mcatanzaro, pnormand, slomo, tmpsantos | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Bug Depends on: | 142978 | ||||||
Bug Blocks: | 110014 | ||||||
Attachments: |
|
Description
Michael Catanzaro
2015-01-04 20:00:21 PST
Created attachment 243957 [details]
Patch
Comment on attachment 243957 [details] Patch Clearing flags on attachment: 243957 Committed r177896: <http://trac.webkit.org/changeset/177896> All reviewed patches have been landed. Closing bug. 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. Disabling the plugin scanner can't be the right solution for this approach, and if there's no other way I would say that seccomp is currently broken by design. (In reply to comment #4) > Disabling the plugin scanner can't be the right solution for this approach, > and if there's no other way I would say that seccomp is currently broken by > design. I'm glad I CCed you. Let's discuss this in bug #140131. Re-opened since this is blocked by bug 142978 Go away bug, we'll use bug #140131 for this. |