4 ms·

Flatpak already does this. It is called portal. The grandparent post is wrong. The problem is what haplens when the program does not use standard file choosers

Flatpak already does this. It is called portal. The grandparent post is wrong. The problem is what haplens when the program does not use standard file choosers, file APIs, etc.

necovek 6y ago
Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc."). Suddenly, it's now on app developer to support the packaging system and not the other way around.
- Spivak 6y ago
  I mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog? macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.
  - orra 6y ago
    TBF you could put support into the two common GUI toolkits, to defer to a Flatpak portal.
    - Spivak 6y ago
      But that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.
      - orra 6y ago
        Well, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck. It wouldn't surprise me however if sandboxing is only a good model for GUI not console app. IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.
        AshamedCaptain 6y ago
        As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.
  - GekkePrutser 6y ago
    And also because macOS has only one desktop environment :)
amelius 6y ago
Can't the sandbox override the corresponding syscalls? E.g. open() and readdir() which then block until the user has selected the file? This means you'll have to click the file twice (once for the sandbox and once for the application) but at least it is more secure.

Flatpak already does this. It is called portal. The grandparent post is wrong. The problem is what haplens when the program does not use standard file choosers, file APIs, etc.

necovek 6y ago

Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc."). Suddenly, it's now on app developer to support the packaging system and not the other way around.

Spivak 6y ago
I mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog? macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.
- orra 6y ago
  TBF you could put support into the two common GUI toolkits, to defer to a Flatpak portal.
  - Spivak 6y ago
    But that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.
    - orra 6y ago
      Well, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck. It wouldn't surprise me however if sandboxing is only a good model for GUI not console app. IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.
      - AshamedCaptain 6y ago
        As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.
- GekkePrutser 6y ago
  And also because macOS has only one desktop environment :)

amelius 6y ago

Can't the sandbox override the corresponding syscalls? E.g. open() and readdir() which then block until the user has selected the file? This means you'll have to click the file twice (once for the sandbox and once for the application) but at least it is more secure.