Well, we've seen sandboxes on other desktop platforms (OSX, WinRT, ChromeOS), and so far, they all are horribly limiting. So, I'm making sure the same does not happen on Linux, before we get kicked out of our own platform.
> 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.
> Raw device access will not happen by just having the app open the raw device nodes. Instead we'll have some kind of service in the session that (via user interaction or "remembered" grants from the user) virtualizes access to these things.
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.
Something using GStreamer in Vala to get indirect access to webcams? I don't see how this could even work: how do you control brightness or other webcam controls from two applications, how do you get direct H26x access with preview synchronized? (And asking someone to use a competitive project to get video input is also a bit rude, but that's beside the subject)
> Why does not pulseaudio work?
libpulse requires X, as far as I know.
> OpenGL access is supported
Through Wayland? How do I get YUV surfaces? What about overlay? What about VDPAU/VAAPI? I guess this will get a lot of improvement, because wayland, wl_scaler (et al) are very limited, so far.
We'll see how it fares, but from the past interactions, the answers were pretty dismissive; and therefore, I'm not that optimistic about the outcome.
>> 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).
Maybe 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.
At 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.
The 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.
I'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.
> 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.
Yeah, the possibility of a "gatekeeper effect" is what's worrisome here. There's no way you can anticipate everything a user might want to do with their computer, so while opt-in sandboxing can only help, mandatory sandboxing could stifle the creativity of developers who must go through a gatekeeper (even a benevolent one) any time they want to ship a program that uses hardware or software abstractions in some unforeseen way.
Or alternatively, Joe User goes "[grumble grumble] guess I gotta delete that dang PulsePolicyD that's keepin' me from runnin' muh binaries [copies and pastes the first command found when googling "how i run X" into shell]" and it's all for naught.
> I'm making sure the same does not happen on Linux, before we get kicked out of our own platform.
To make one thing very clear:
Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This sandboxing (together with other bits) would allow you to distribute your application eventually 80% of the various Linux distribution users. I think it'll take some time because there's a lot of things to work out (e.g. relying on Wayland, kdbus, change Pulseaudio to use kdbus, etc).
A user should have control on what an application can do, but that's something new and user might highly prefer such applications (e.g. not allowing an application to just modify ~/.bashrc and adding some evil sudo alias if it feels like it).
IMO at most you'd have some package software which shows for VLC: "unrestricted access". The intention is to offer more security where possible to the user while at the same time it's not too difficult for the developer.
> To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution.
This is not what we understand from your GnomeOS talks and systemd "distributions are obsolete" posts.
>> 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.
If the file chooser is powerful enough, couldn't it be?
I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as I'm concerned.
> Experience from OS X and WinRT is that they aren't powerful.
And I'm not suggesting that the current state of things is sufficient.
> What about mkv linked files or .mpc lossless complements? Or cue/bin complements?
> What about m3u that have mp3, ogg and flac interleaved?
In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple.
Presumably, if I did use those formats, the ability to grant ~/music/.../.{mp3,ogg,flac} or ~/music/ is not a huge step from granting access to *.mp3. If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.
We already deal with some of this, with dialogs prompting us about which file types we want to associate with our media players. Reuse and retool those, profit?
> In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple.
You don't use mkv or playlists with mixed content? You don't use subtitles?
> the ability to grant ~/music/.../.{mp3,ogg,flac} [...] If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.
Your first idea is that our codebase is bitrot? Seriously?
> which file types we want to associate with our media players. Reuse and retool those, profit?
And you know, it's been a long time we don't rely on extensions for format detection.
Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.
> You don't use mkv or playlists with mixed content? You don't use subtitles?
No MKV, mp3-only playlists, and then only subtitles I use are those embedded within the .avi / .mp4. I'll certainly admit I'm not VLC power-user.
> Your first idea is that our codebase is bitrot? Seriously?
You've chopped far too much context. I'm assuming your codebase supports neither whitelist in it's current form - reasonable, nothing needs it yet. That is my first idea.
I'm also meaning to imply that you're overstating how difficult it would be, if your codebase did support interacting with the standbox to request .mp3 whitelisting, to request other formats as well. That is my second idea.
My third* idea, at best, is that your codebase has bitrot. This is not me intending to slight you, your project, your contributors, your former contributors, or any of the choices involved. This is not me saying I am better than any of that. This is me, where half of my last job was dealing with bitrot, some caused by my own hand - trying to relate, while trying to identify where such a hypothetical, assumed to be serious problem, would actually lay.
> And you know, it's been a long time we don't rely on extensions for format detection.
You might not, but windows still does. Is this dialog gone?
> Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.
I apologize if it came off that way, and for touching a nerve. But please understand me. The sin you're looking for is Envy, not Arrogance, within me if you've had that leisure - of dealing only with pristine codebases without serious problems.
Well, we've seen sandboxes on other desktop platforms (OSX, WinRT, ChromeOS), and so far, they all are horribly limiting. So, I'm making sure the same does not happen on Linux, before we get kicked out of our own platform.
> 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.
> Raw device access will not happen by just having the app open the raw device nodes. Instead we'll have some kind of service in the session that (via user interaction or "remembered" grants from the user) virtualizes access to these things.
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.
> For an example of the later, for webcams see the pulse-video project: https://github.com/wmanley/pulsevideo
Something using GStreamer in Vala to get indirect access to webcams? I don't see how this could even work: how do you control brightness or other webcam controls from two applications, how do you get direct H26x access with preview synchronized? (And asking someone to use a competitive project to get video input is also a bit rude, but that's beside the subject)
> Why does not pulseaudio work?
libpulse requires X, as far as I know.
> OpenGL access is supported
Through Wayland? How do I get YUV surfaces? What about overlay? What about VDPAU/VAAPI? I guess this will get a lot of improvement, because wayland, wl_scaler (et al) are very limited, so far.
We'll see how it fares, but from the past interactions, the answers were pretty dismissive; and therefore, I'm not that optimistic about the outcome.