Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First fully sandboxed Linux desktop app

blogs.gnome.org

Post reply on HN
Print view View original

101–110 of 136 posts

Re: First fully sandboxed Linux desktop app

#101

Post by pmontra »

detaro wrote: post #99
cplease wrote: post #91

Earlier quoted context omitted.

> I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect. You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their res…

A file chooser outside the application is safer if the sandbox enforces that only selected files are opened. Of course I want the app to be able to read files I told it to open, but it shouldn't be able to access files I haven't selected.

How about the sub files with the same name of the video file you selected? Some players open them automatically and it's very convenient. I'm sure there are other cases like that.

Re: First fully sandboxed Linux desktop app

#102

Post by detaro »

pmontra wrote: post #101
detaro wrote: post #99

Earlier quoted context omitted.

A file chooser outside the application is safer if the sandbox enforces that only selected files are opened. Of course I want the app to be able to read files I told it to open, but it shouldn't be able to access files I haven't selected.

How about the sub files with the same name of the video file you selected? Some players open them automatically and it's very convenient. I'm sure there are other cases like that.

Just because it can't cover every single case and application doesn't mean it isn't worth using it for those where it fits. It's an interesting question how far one would want to go to support these special cases, because doing so adds complexity to both code and the things the user has to understand, but the nice thing with an open system is: we don't have to use it for applications that don't fit the model very well or can allow exceptions where needed.

Re: First fully sandboxed Linux desktop app

#103

Post by tracker1 »

jbk wrote: post #2

It's really nice to see that happening, but every time I raised the subject with the Gnome team to see how we could run VLC in it, it's a no-go. Indeed, for a complete media player, I need: - access to files not directly opened by the user (playlists, MKV, DCP, MXF), - access (and unique probably) to raw devices read-only (DVD, AudioCD, Blu-Rays, webcams-v4l2, SDI, DVB), - direct access to raw audio output, - access…

what's wrong with having a service layer that isn't sandboxed, and an application layer that is?

What's stopping you from running your filesystem and network requests through a local service... you can sandbox all the rendering and other access, and tighten controls on your service interface.

Re: First fully sandboxed Linux desktop app

#104

Post by timthelion »

While I'll admit that my personal project, subuser.org isn't yet at the stage of 100% sandboxed, this title is excedingly misleading. There are lots of projects that have done this allready: http://www.jann.cc/2014/09/06/sandboxing_proprietary_applica..., https://github.com/Kagami/kagome

Re: First fully sandboxed Linux desktop app

#106

Post by MaulingMonkey »

jbk wrote: post #70
MaulingMonkey wrote: post #60

Earlier quoted context omitted.

>> 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…

> If the file chooser is powerful enough, couldn't it be? Experience from OS X and WinRT is that they aren't powerful. > I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 What about mkv linked files or .mpc lossless complements? Or cue/bin complements? What about m3u that have mp3, ogg and flac interleaved? It's not that simple.

> 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?

Re: First fully sandboxed Linux desktop app

#107

Post by [deleted] »

jbk wrote: post #2

It's really nice to see that happening, but every time I raised the subject with the Gnome team to see how we could run VLC in it, it's a no-go. Indeed, for a complete media player, I need: - access to files not directly opened by the user (playlists, MKV, DCP, MXF), - access (and unique probably) to raw devices read-only (DVD, AudioCD, Blu-Rays, webcams-v4l2, SDI, DVB), - direct access to raw audio output, - access…

[deleted]

Re: First fully sandboxed Linux desktop app

#108

Post by MaulingMonkey »

wlesieutre wrote: post #65
wlesieutre wrote: post #64

Earlier quoted context omitted.

Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.

That actually took a couple of edits with inconsistent results. Sometimes it actually prints the backslash? \* \*. And it definitely likes having a space in between, otherwise the second slash gets styled in italics. Curious.

Yeah, double backslash was the first edit I tried :)

Re: First fully sandboxed Linux desktop app

#110

Post by [deleted] »

wlesieutre wrote: post #65
wlesieutre wrote: post #64

Earlier quoted context omitted.

Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.

That actually took a couple of edits with inconsistent results. Sometimes it actually prints the backslash? \* \*. And it definitely likes having a space in between, otherwise the second slash gets styled in italics. Curious.

[deleted]
Post reply on HN