GNOME Bugzilla – Bug 607932
Create a sandboxed playback element
Last modified: 2018-11-03 11:16:16 UTC
GStreamer should provide a playback element that separates the network IO and decoding from rendering. Demuxers and decoders are more likely to contain security bugs and should be separated as much as possible from the rest of the playback pipeline. Source/demuxing/decoding should ideally be done in one process and communicate and send the data over shmem/pipe etc to another process which is only sending the decoded data to the audio and videosink. See also: http://code.google.com/p/chromium/issues/detail?id=32861#c23
I wrote a pair of shmsrc/shmsink elements that provide a pipe-like interface using shared mem for that kind of case.
Or you could simply use gdp over TCP or unix domain sockets. In the case of chromium it would probably be a better/easier solution to do all GStreamer stuff in a separate process and just embed the video sink into the chromium window.
I'm not sure if GDP would suffice, ideally the process which does the rendering should contain initial setup code and after that point it should only working on existing state. Eg, no file system access, no memory allocation, only use existing file descriptors with a limited set of system calls (read/write).
The shmsrc/sink have a shmpipe.[ch] files that are non-gst dependant and that you can use in your main app to transfer the data.. That said, the shm stuff doesn't carry timestamps or caps or anything like that. But it does provide zero-copy if your shared memory buffer is large enough to use it as a queue.
Is anybody planning to work on this? There is this here also http://guij.emont.org/blog/2012/05/08/video-decoding-in-a-sandbox/ I think it would be great to have a generic sandboxing mechanism in GStreamer that allows to run any part of a pipeline inside a different process, while having this completely transparent for all involved GStreamer elements... by implementing all of the GstElement/GstPad API via IPC.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/29.