4 ms·
>> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. >This is not enough, as
by alexlarsson 12y ago
>> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose.
>This is not enough, as explained above.
Well, its hard to say that as this kind of stuff is not designed yet. Better to say that the requirements of VLC on the design of this are more complex than just the "allow access to single-picked-file" semantics. Hopefully we can take this into account when we look into the details here.
> Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know.
Some of these need not necessarily be as complex as you imagine though. They could very well be some kind of thin service that enumerates the real devices and hands over the opened FD to your app after having verified that it is allowed.
> libpulse requires X, as far as I know.
Libpulse can optionally be built with X, but this is really only used to read back the pulse socket name from the x root property. It works just fine without X (witness the non-X, but pulseaudio using demo in the blog post for instance).
OpenGL access is via DRI, but yeah, output to the screen will have to happen via wayland. That could use subsurfaces with YUV surfaces, and it is then up to the compositor to use overlays if possible (i know weston does this for instance).
For VDPAU etc, i don't really know.
- jbk 12y ago> Hopefully we can take this into account when we look into the details here. This is all I'm asking, and not the usual "I don't care about your usecase, you should just use GStreamer" that we get from the Gnome/RedHat/Systemd team.
- greggman 12y agoMaybe I'm missing it but I don't see how DRI is really sandboxing OpenGL. Note: I helped write the OpenGL sandbox in Chrome and it's certainly possible I don't know the details of DRI enough to understand how it sandboxes but I do know what we had to do to sandbox OpenGL in Chrome, that includes re-writing shaders since we can't trust the driver, clearing buffers since OpenGL doesn't and so you can read other processes' data, and many other things and as far as I can tell DRI isn't doing things like that.
- lunixbochs 12y agoI'm pretty sure DRI doesn't do anything special to the OpenGL calls, so they just get punted into the scary binary client library from your GPU vendor.
- alexlarsson 12y agoAt the moment we grant all of /dev/dri, but long term we want only the render nodes accessible. That gives us no modesetting or DRM master capabilities, only rendering. It is true though that the drivers could very well have leaks in them, but the userspace sandbox is not the place to fix that, it is the drivers themselves. The intent is for the dri driver APIs to give guarantees about client separation, but I'm sure it needs work.
- greggman 12y agoThe drivers will never be fixed. Chrome doesn't trust them. It's not in their interest to fix them since sales are determined by performance not by security.