Hacker News Reader

Comment by jsnell | Hacker News Reader

So Flatpaks also install under /var? That's horrible, I thought it was only Snaps that made that decision :( Does anyone know what the official reasoning for this is?

View on HN

It's mind boggling. The entire premise of being "sandboxed" means unable to escape the box and access the rest of the system. By that, one would think a Flatpak or any similar package would keep itself contained to the user's home directory, so that even if it broke out of the sandbox its path of destruction would be contained to the user's files (still not a great thing but not system-owning).

Where the app is installed and what it can access are separate things.

Also, it's fairly easy to reinstall the OS but people are more concerned about their home directories being damaged or exfiltrated.

The safety of your home directory relies on the integrity of the operating system.

The point is that if you run an app with FS access to your home directory, you are already screwed. OS integrity does not matter in that case.

> So Flatpaks also install under /var? That's horrible

Why?

At a minimum they need access to a directory the user cannot subvert. If they were entirely contained to $HOME, then an attacker who found an unlocked shell can subvert all the apps. If the packaging format allows running apps or daemons then that means a system compromise.

It is also extremely common for $HOME to be a network drive or even a USB stick, so better to cache stuff in /var which can be assumed to be local storage.

Flatpaks use a git-like tree of hashes, which cant just be shoved into random places on your filesystem. It has an exports directory you can symlink or add to your path.

In that case it should be in /opt, where application bundles not managed by the system's primary packaging system belong.

This isn’t technically correct when Flatpak is installed via your distribution. Then it is managed by your packaging system and it’s data should live in a /var/lib.

/opt is for software that doesn’t adhere to the FHS and can’t/shouldn’t be installed in a prefix. Red Hat and Arch install software to /opt via their official package managers. /opt isn’t safe to stick arbitrary software even though it’s commonly used for that — /opt/local is the non-FHS equivalent of /usr/local.

> This isn’t technically correct when Flatpak is installed via your distribution. Then it is managed by your packaging system and it’s data should live in a /var/lib.

Besides, this is silly: they go in /var/lib/flatpak, which is for flatpak's program state information. (Exported desktop files and whatnot go to /var/lib/flatpak/exports/, which is pointed to by `$XDG_DATA_DIRS`).

I mean, if you want to go all Militant Unix Admin on it and install apps to /opt, you can `man flatpak` and set `FLATPAK_SYSTEM_DIR=/opt/flatpak`, but unless your system spans a dozen hard drives I'm not sure what that's going to achieve.

I guess this is sort of an ownership conundrum: a flatpak app is run _via_ flatpak. On its own, it's just a heap of files.

Agreed, that's what /opt is for.

or you can install in your user directory, current cli of flatpak ask you for this and you can set the default install option for the user directory also

Reply on news.ycombinator.com