Not on Windwows or on macOS.
> new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy.
Of course that does not solve anything, because your demuxer|decoders|output needs access to the FS, have access to kernel-mode and those are the dangerous parts.
> Not on Windwows or on macOS.
It's a shame, then, that Windows & macOS are holding back security improvements for software running on Linux. I understand (& even agree with!) your desire to have a sandboxing mechanism which runs acceptably on all supported systems; it's just sad that this security mechanism in the Linux kernel can't be taken advantage of in vlc.
The demo is on Windows. The goal is to do a sandbox that works on most OSes.
And, it will not solve the decoder issue, since it is on the decoding side, which still has access to the GPU/Aout and the kernel.
> Read access to an existing FD is not the same as full FS access, and there's no demux involved here.
You're totally missing the point here. The issue is demuxers/decoders/output, not really the access.
Reading from an FD or not would not solve the buffer overflow exploitation (if it was actually exploitable).
Feels kinda pointless, since all threads in a process share the same memory protection.
It's more coding, certainly, but it's possible. Security is an option if we wanted it.
Other points may be more tricky, and it's a good list of potential issues, but we can start chipping away some stuff right now. There's a lot we can fix without fixing everything at the same time.