flatpacks falling flat, packing bugs, snaps snapping resources, both suck [LWN.net]

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 9:58 UTC (Tue) by mbunkus (subscriber, #87248)
In reply to: flatpacks falling flat, packing bugs, snaps snapping resources, both suck by intelfx
Parent article: Fedora discusses Flatpak priorities

I haven't thought about how file access might be sandboxed better because I'm not interested in designing such systems. I'm simply observing & reacting to how it affects me as an application developer. To me it seems that the sandboxes targeting the Linux desktop use the "require user interaction for each file accessed" model. This has two problems that I can see right from the start:

1. The "files referencing other files" issue I've already mentioned
2. Making it much harder for cli-only applications as they usually don't use GUI libraries such as Qt, meaning there's no easy way to shove portal-like functionality in there without having to adjust your code — but I may be wrong here; I simply have never seen it (Flatpak is very much tailored towards GUI applications; as a matter of fact you cannot package cli-only applications as Flatpaks properly)

There are two other sandboxing systems out there that I know about tangentially: Android & systemd. I know little about Andoid, but what little I know seems to be a two-part system: an application always has access to its own private piece of land within the file system that no other application has access to, and you can grant it access to the rest of the non-system parts of the file system via Android's permission system. It's not as fine-granular as Flatpak's system but requires much less interaction. It benefits from the fact that Android itself has a rigid design that it can impose on all applications, unlike generic Linux systems where users can store files anywhere, really.

systemd's sandboxing system is quite fine granular as you can set up certain paths to be read-only, others to be read/write, restrict capabilities etc. However, this setup is required before the program is started, meaning the admin has to know in advance which parts of the file system will be accessed in which way. This works fine for well-known daemons; it doesn't work so well for applications dealing with general user data such as LibreOffice or my own applications. In my case users often have stuff in their home, or on mounted network shares, on in places such as /data on different partitions etc. etc.

Again, I have no solutions here. This is a hard problem. Maybe there isn't a good one-model-fits-all solution at all, though I hesitate to say that as I certainly lack the knowledge in the area of sandboxing techniques to make such an assertions.

Maybe I'm just a bit annoyed with statements such as "<sandboxing technique> apps are more secure as they limit what the application can access". Yeah, it's partially true, and I'm probably just an annoying nitpicker.

to post comments

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 10:18 UTC (Tue) by intelfx (subscriber, #130118) [Link]

> I know little about Andoid, but what little I know seems to be a two-part system: an application always has access to its own private piece of land within the file system that no other application has access to <...>

> systemd's sandboxing system is quite fine granular as you can set up certain paths to be read-only, others to be read/write, restrict capabilities etc. However, this setup is required before the program is started

Flatpaks also have their own internal store that they can access freely without any permissions. They also have an option to statically require RO or RW access to specific parts of the host filesystem (like systemd daemons).

> <...> and you can grant it access to the rest of the non-system parts of the file system via Android's permission system

Like you said, in Android's case, this likely only works because *almost all* storage is compartmentalized. So "non-system parts of the file system" is basically "free-form user files". There's no way for an app to abuse this grant to access system files or, importantly, other apps' files.

On Linux, this is not an option — direct filesystem access (even limited to non-system files) is a much broader brush. Except, maybe, if you filter all the dotfiles via some kind of security layer (and even then, you'll eventually get stuck with either false-positives or false-negatives).

Perhaps what's missing is just an ability for an app to request access to the containing directory along the user-picked file, or request access to a precomputed path. Does not sound like a *fundamental* problem to me — has anyone tried asking the XDG guys to add this to the relevant portal spec?