[Webkit-unassigned] [Bug 188568] [GTK][WPE] Implement subprocess sandboxing

[bugzilla-daemon at webkit.org]

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

--- Comment #13 from Patrick Griffis <pgriffis at igalia.com> ---
(In reply to Adrian Perez from comment #11)
> Some systems may not use PulseAudio at all, and in that case the GStreamer
> autoplugging machinery will choose ALSA (or even OSS!) if possible. I think
> almost nobody is using OSS on GNU/Linux anymore in 2018, so I think at least
> we should bind “/dev/snd” inside the sandbox. That would also cover for cases
> like people configuring audio capture to use some particular ALSA device
> instead of PulseAudio. One example of the latter that I have witnessed is
> having a headset for confcalls that has an USB-audio interface but Pulse
> would not pick it up somehow.

Michael said it was reasonable to focus on Pulseaudio (at least in context of GTK).

The reality is that Pulseaudio is no safer than raw ALSA atm (Pipewire will be our
savior perhaps) so I guess its fine to add raw dev access.

> > Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:327
> > +        "--dev-bind-try", "/dev/nvidia", "/dev/nvidia",
> 
> While this list is a good initial approach that covers (all?) the Open
> Source drivers (which are the sane ones, and have their device nodes
> under “/dev/dri”), and a couple of extra cases (nice to see the entries
> here already for Nvidia users), there are a few many proprietary drivers
> which are not covered. For example we have WPE running on Adreno GPUs
> that make “/dev/kgsl-3d0” and “/dev/ion”.
> 
> But the story does not end there: WPE can (and sometimes will) run without
> a windowing system, which on some platforms means there is some WPE backend
> implementation which may e.g. use old style framebuffer devices (“/dev/fbN”)
> or even some custom device nodes.
> 
> I guess there's no better good way of doing this without adding entries
> to the whitelist later on as we keep finding more cases of “bad” drivers
> which have their device node paths outside of “/dev/dri” :-(

Indeed, I'll add the ones you mentioned.

-- 
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/20180817/53021b77/attachment.html>