6 ms·

I never understood why a program installed in Flatpak is not just a directory on disk. When you install something via Flatpak, it still changes data in god-kno

by TekMol 20d ago

I never understood why a program installed in Flatpak is not just a directory on disk. When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk. The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.

kodoman 20d ago
I use podman for things like this, works perfect until you want desktop applications but you can hack it about a bit to work fine with pipewire and Xephyr and you have. I feel like a lot of these desktop container systems are horrible and are quite hostile to configuring in the way you want around permissions and such and podman or docker does a better job.
- jbstack 20d ago
  > Xephyr Given that X11 is becoming more and more obsolete over time, what's the Wayland option?
  - kodoman 20d ago
    Not using Wayland I am not 100% sure, I think Xephyr works in XWayland and I think their is a similar tool to Xephyr for setting up an embedded Wayland session (I would have thought this is even easier and more elegant in wayland but not sure). So could be even better. I personally use X11 as I am on exwm and exwm does not support wayland and no alternative to it does AFAIK (I think theirs a POC floating around somewhere). Also I know X11 even though it's a bit crap in many ways it's the devil I know.
- Timon3 20d ago
  I've had very good experiences with desktop applications in containers using Distrobox & podman. It handles all the integration into the host system, so video, audio etc. just work. The default configuration is probably too well-integrated if you're looking to use it as a sandbox, but there should be ways to turn parts off.
schmorptron 20d ago
I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?
vaylian 20d ago
> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach. That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.
- alkonaut 20d ago
  Can't it request and be granted that permission, transparently to the app? E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues? At least that's how I'd thought it would work. Perhaps this isn't viable?
  - weiran 20d ago
    It’s how sandboxed Mac apps work today.
  - danielheath 20d ago
    Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places. Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places. How many permission prompts will users tolerate?
    - alkonaut 20d ago
      I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently. If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
    - 20d ago
lunar_rover 20d ago
Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind. If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.
meibo 20d ago
It's up to you, really, to only use flatpaks that declare tight permissions and implement the proper protocols to safely access resources they don't declare. This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.
- Gigachad 20d ago
  It’s also just hard to make breaking changes on Linux. Apple can declare something is changing and you have 1 year to get with the program. In Linux you have to bargain and plead with devs over 10 years to change something. Restricting an app to not have file system access is a breaking change. It would have been dead in the water if they didn’t meet half way and make file system access an optional permission.
  - mike_hearn 20d ago
    Apple has much better backwards compatibility than Linux. The APIs haven't changed much since the Carbon->Cocoa transition 25 years ago, and SwiftUI (but that's optional). The impact of app sandboxing on developers was small - and sandboxing is universal on macOS now, there are only different levels of sandboxing but no such thing as unsandboxed apps anymore. Apple's introduction of sandboxing to an app ecosystem designed without it was a masterclass in OS design that goes unappreciated in our industry. Nobody else pulled that off. It's no exaggeration to say that macOS is the most secure desktop OS by a long way, it's not even close. Linux trails far behind in third place. They achieved this via: • Extremely long term planning (multi-decade timescales). • Extremely good systems design. • Incremental change, so developers always had a digestable chunk of work at any given point. The work needed was smeared out over decades, not drop-kicked onto people in ways that left them flailing. • Good developer relations work to ensure devs got help quickly if they hit issues. At no point has Apple's security team had to change course, reverse a prior decision, redesign a subsystem or fail to meet their goals. Everything has slowly clicked together so smoothly most people, even devs, didn't even notice it happening. The sad thing is, the engineers who pulled this off are largely unknown. The head of Apple Security came from the One Laptop Per Child project and deserves a lot of credit, but much of the careful detailed design that makes the Apple security architecture work is done by unsung heroes. One guy was known only by the name "Perry the Cynic"! Edit: I did some searches. Perry the Cynic was Peter Kiehtreiber, who seems to now be retired.
bashZorina_09 20d ago
Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"? Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach. I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.
kalaksi 20d ago
Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter
- cassianoleal 20d ago
  > The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter It's not when that choice is never presented to the user.
pinkwah 20d ago
By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`. Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory. The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory. Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
- hattar 20d ago
  > Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents. What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
  - NekkoDroid 20d ago
    > What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
654wak654 19d ago
I think most people making a good ol' desktop program these days do it because they need very liberal access to the filesystem, or access to weird hardware peripherals. If they don't need either they could just put their app on the web! Looking at the top apps on Mint's "app store" shows this trend too, everything is an editor of sorts (code editors, photo editors, video editors, audio editors, painting, modelling etc.)
VCFundedGenYer 19d ago
This is false. $HOME/.var/app is where it's stored. Use flatseal (or terminal) to adjust permissions.
Shorel 19d ago
As everyone else has written, two very different things are being mentioned n your last paragraph: First, the application should be just a directory on disk. I wholeheartedly agree, this should be the way to install applications, and OSX has shown that this works wonders. Second: it being limited to only read and write files in that directory. No, that's the wrong idea, the application should be associated with some extensions and should be able to edit documents in your Documents directory. It makes no sense otherwise.

by TekMol 20d ago

kodoman 20d ago

I use podman for things like this, works perfect until you want desktop applications but you can hack it about a bit to work fine with pipewire and Xephyr and you have. I feel like a lot of these desktop container systems are horrible and are quite hostile to configuring in the way you want around permissions and such and podman or docker does a better job.

jbstack 20d ago
> Xephyr Given that X11 is becoming more and more obsolete over time, what's the Wayland option?
- kodoman 20d ago
  Not using Wayland I am not 100% sure, I think Xephyr works in XWayland and I think their is a similar tool to Xephyr for setting up an embedded Wayland session (I would have thought this is even easier and more elegant in wayland but not sure). So could be even better. I personally use X11 as I am on exwm and exwm does not support wayland and no alternative to it does AFAIK (I think theirs a POC floating around somewhere). Also I know X11 even though it's a bit crap in many ways it's the devil I know.
Timon3 20d ago
I've had very good experiences with desktop applications in containers using Distrobox & podman. It handles all the integration into the host system, so video, audio etc. just work. The default configuration is probably too well-integrated if you're looking to use it as a sandbox, but there should be ways to turn parts off.

schmorptron 20d ago

I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?

vaylian 20d ago

> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach. That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.

alkonaut 20d ago
Can't it request and be granted that permission, transparently to the app? E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues? At least that's how I'd thought it would work. Perhaps this isn't viable?
- weiran 20d ago
  It’s how sandboxed Mac apps work today.
- danielheath 20d ago
  Apps built with a toolkit which ships its own filepicker will immediately attempt to enumerate directories in `/`, `/home`, and probably a few other places. Apps with a config file will often try to read `~/.config/myapp` and also `~/.myapp/config` and maybe one or two other places. How many permission prompts will users tolerate?
  - alkonaut 20d ago
    I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently. If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.
  - 20d ago

lunar_rover 20d ago

Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind. If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.

meibo 20d ago

It's up to you, really, to only use flatpaks that declare tight permissions and implement the proper protocols to safely access resources they don't declare. This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.

Gigachad 20d ago
It’s also just hard to make breaking changes on Linux. Apple can declare something is changing and you have 1 year to get with the program. In Linux you have to bargain and plead with devs over 10 years to change something. Restricting an app to not have file system access is a breaking change. It would have been dead in the water if they didn’t meet half way and make file system access an optional permission.
- mike_hearn 20d ago
  Apple has much better backwards compatibility than Linux. The APIs haven't changed much since the Carbon->Cocoa transition 25 years ago, and SwiftUI (but that's optional). The impact of app sandboxing on developers was small - and sandboxing is universal on macOS now, there are only different levels of sandboxing but no such thing as unsandboxed apps anymore. Apple's introduction of sandboxing to an app ecosystem designed without it was a masterclass in OS design that goes unappreciated in our industry. Nobody else pulled that off. It's no exaggeration to say that macOS is the most secure desktop OS by a long way, it's not even close. Linux trails far behind in third place. They achieved this via: • Extremely long term planning (multi-decade timescales). • Extremely good systems design. • Incremental change, so developers always had a digestable chunk of work at any given point. The work needed was smeared out over decades, not drop-kicked onto people in ways that left them flailing. • Good developer relations work to ensure devs got help quickly if they hit issues. At no point has Apple's security team had to change course, reverse a prior decision, redesign a subsystem or fail to meet their goals. Everything has slowly clicked together so smoothly most people, even devs, didn't even notice it happening. The sad thing is, the engineers who pulled this off are largely unknown. The head of Apple Security came from the One Laptop Per Child project and deserves a lot of credit, but much of the careful detailed design that makes the Apple security architecture work is done by unsung heroes. One guy was known only by the name "Perry the Cynic"! Edit: I did some searches. Perry the Cynic was Peter Kiehtreiber, who seems to now be retired.

bashZorina_09 20d ago

Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"? Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach. I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.

kalaksi 20d ago

Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter

cassianoleal 20d ago
> The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter It's not when that choice is never presented to the user.

pinkwah 20d ago

By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`. Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory. The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory. Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.

hattar 20d ago
> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents. What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
- NekkoDroid 20d ago
  > What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).

654wak654 19d ago

I think most people making a good ol' desktop program these days do it because they need very liberal access to the filesystem, or access to weird hardware peripherals. If they don't need either they could just put their app on the web! Looking at the top apps on Mint's "app store" shows this trend too, everything is an editor of sorts (code editors, photo editors, video editors, audio editors, painting, modelling etc.)

VCFundedGenYer 19d ago

This is false. $HOME/.var/app is where it's stored. Use flatseal (or terminal) to adjust permissions.

Shorel 19d ago

As everyone else has written, two very different things are being mentioned n your last paragraph: First, the application should be just a directory on disk. I wholeheartedly agree, this should be the way to install applications, and OSX has shown that this works wonders. Second: it being limited to only read and write files in that directory. No, that's the wrong idea, the application should be associated with some extensions and should be able to edit documents in your Documents directory. It makes no sense otherwise.