This is such a headache with snap and flatpak though.
If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges".
Some examples of sandboxing issues:
* FreeCAD doesn't have access to /usr which means when you try to make a Draft ShapeString you can't pick any fonts
* FreeCAD stores the path to the shape of a milling cutter inside your project, but that path is inside /mnt/.FreeCAhjhffg or whatever so it doesn't work after you restart the program
* Inkscape gcodetools has its own "idiomatic" way of saving out results which doesn't use a file dialog, and therefore can't save any gcode because it can't write to your home directory
* Matrix is only allowed to access ~/Downloads/ which means you can't share any files with anyone unless you copy them into Downloads first
* "Recent" in the Gimp file picker doesn't show any of my recent files, presumably because it is using its own sandboxed file dialog which doesn't have access to the actual "Recent" files
* Docker can't access /tmp/.X11-unix which means you can't give docker containers access to X
In all of these cases you can work around it of course (mainly by having an accurate mental model of the problem and guessing a path that the program is allowed to access), but the user experience is just made worse for no benefit.
The general theme is that the user wants the sandboxed program to be able to do something that the person who assigned privileges didn't think of.
So maybe if we must do sandboxing, let's make it easy for users to break programs out of the sandbox when it suits them?
This looks like a chicken and egg problem to me. You can't sandbox things properly because things don't specify their required privileges properly. Things don't specify their privileges properly because things aren't sandboxed so there's no need to think about that.
As a user, I quite like the iOS approach, of apps "sharing" their ressources with other apps or asking for permission to access this or that collection of ressources. This can probably be improved and adapted to a non-touch model, but I think the concept is nice.
But, of course, apps have to be built for this kind of environment, so I think there will unfortunately be some janky transition period, with the customary competing, incompatible implementations.
Firejail sandboxing works well on these scenarios. You can trivially grant more or less privileges, including the removal of the entire sandbox if you wish.
It actually ships with rulesets for hundreds of programs that tend to be quite polished and work out of the box.
Personally, I dislike flatpak because it doesn't let me control the dependencies of packaged software, and I feel we loose one of the most important advantages of Linux.
You raise many good points. One of the primary reasons I don't use nix or guix for everything is because it seems like there's too much magic and it's often too difficult for me to figure out how to modify a detail if a toggle wasn't explicitly provided for it. Even just getting insight into the chain of events to debug things was incredibly obtuse the last time I played with nix. Like cmake on steroids. At least cmake will spit out a multi-megabyte trace file for me to pick through. (I'm convinced cmake is an elaborate conspiracy to waste developer time.)
> let's make it easy for users to break programs out of the sandbox when it suits them?
At least for Flatpak given the things you described this is quite straightforward via bind mounts. Although it did seem a bit goofy having an entire list of per-application bind mounts in my fstab. Maybe things have improved since I last tried going that route?
> "idiomatic" ... doesn't use a file dialog,
That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals for all supported operations at this point. The only excuse (IMHO) is for missing or broken functionality.
It would be like a system tray widget not working and blaming the DE instead of the program that fails to implement the decently old and widely adopted standard.
> Matrix ... you can't share any files with anyone
Which client is this? Anyway the xdg portal should work. Did the dev try it? Programs should never need blanket access to save or open specific user supplied paths as a one off. That's a large part of the point of sandboxing stuff in the first place.
> if they "aren't" doing that then it doesn't help.
True enough. To be clear I don't fault anyone for not using new or known to be broken or little known standards.
However at some point responsibility has to shift to the developers. There are standard ways of doing things. Just as you can't expect an arbitrary project to support your pet API that hardly anyone uses, developers can't expect major distributions or the majority of users to cater to their refusal to conform to widely accepted standards.
I'm not saying you shouldn't use a particular program. Just that I don't think it's reasonable to fault the tooling for certain things.
This is such a headache with snap and flatpak though.
If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges".
Some examples of sandboxing issues:
* FreeCAD doesn't have access to /usr which means when you try to make a Draft ShapeString you can't pick any fonts
* FreeCAD stores the path to the shape of a milling cutter inside your project, but that path is inside /mnt/.FreeCAhjhffg or whatever so it doesn't work after you restart the program
* Inkscape gcodetools has its own "idiomatic" way of saving out results which doesn't use a file dialog, and therefore can't save any gcode because it can't write to your home directory
* Matrix is only allowed to access ~/Downloads/ which means you can't share any files with anyone unless you copy them into Downloads first
* "Recent" in the Gimp file picker doesn't show any of my recent files, presumably because it is using its own sandboxed file dialog which doesn't have access to the actual "Recent" files
* Docker can't access /tmp/.X11-unix which means you can't give docker containers access to X
In all of these cases you can work around it of course (mainly by having an accurate mental model of the problem and guessing a path that the program is allowed to access), but the user experience is just made worse for no benefit.
The general theme is that the user wants the sandboxed program to be able to do something that the person who assigned privileges didn't think of.
So maybe if we must do sandboxing, let's make it easy for users to break programs out of the sandbox when it suits them?