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

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

Posted Mar 19, 2025 13:53 UTC (Wed) by andrejp (guest, #47396)
In reply to: flatpacks falling flat, packing bugs, snaps snapping resources, both suck by farnz
Parent article: Fedora discusses Flatpak priorities

Oh, so you found her already? Good for you, she's yours to keep :)
This particular kitty though only wants /etc/hostname to play with in the sandbox, root(rw) -> root(r-) (you don't want the kitty to mess the toy up, safe-to-play sandbox right?).
Bind mount /etc?

to post comments

Linux bind mounts

Posted Mar 19, 2025 13:58 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

You can bind-mount files as well as directories, under Linux, and have the bind mount reduce permissions as compared to the original pointer to the file. So if you genuinely need read access to /etc/hostname, you can bind-mount that into the sandbox as read only, getting you read access but not write.

That said, if reading /etc/hostname is something your program does often enough for performance of that read to matter, you've got bigger concerns than sandboxing - why are you rereading a value that rarely changes, instead of caching it after first read and invalidating the cache when you get told it's changed?

Linux bind mounts

Posted Mar 19, 2025 14:24 UTC (Wed) by andrejp (guest, #47396) [Link] (1 responses)

> You can bind-mount files as well as directories, under Linux

Really? Well that's new lol. Lemme check.

# cd /tmp
# touch sfile; mkdir sdir
# mount --bind sfile sbox
mount: /tmp/sbox: mount system call failed: Not a directory.
Hm. It does say "Not a dir". Perhaps I'm not doing it right?
# mount --bind sfile sbox/sfile
mount: sbox/sfile: mount point does not exist.
Hm. Perhaps the file must exist before?
# touch sbox/sfile
# mount --bind sfile sbox/sfile
#
Yup. Indeed.
Tnx, I just learned something new :)

Linux bind mounts

Posted Mar 19, 2025 14:40 UTC (Wed) by andrejp (guest, #47396) [Link]

(^^ new for me, it has probably been around for a while)

Linux bind mounts

Posted Mar 19, 2025 14:33 UTC (Wed) by andrejp (guest, #47396) [Link] (3 responses)

> That said, if reading /etc/hostname is something your program does often enough for performance of that read to matter,

No I just made up a trivial test for demonstration purposes. I still wouldn't use a pack/snap for other reasons (have you tried bind mounting a couple of 1000s of files, then ran 'mount' to list them on the host side? that's one of the objections)

But hey, like I said - you find it, you keep it. Though I'm not sure if the kitty would stick around after say 10k bind-mounted files, skittish as she is :)

Linux bind mounts

Posted Mar 19, 2025 14:49 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

Why would you bind-mount 1,000s of files? That's not something that Flatpak normally does (I have several running at the moment, with open files, and only a few bind-mounted files); when you tell the portal that you're finished with a file, the sandbox automatically unmounts the bind-mounted file so that you no longer have access to it.

The only time you'd ever bind-mount 1,000s of files in a Flatpak world is if you've had the user open thousands of files individually, and then not released them - but again, if this hurts performance, why are you keeping thousands of files open?

Linux bind mounts

Posted Mar 19, 2025 15:49 UTC (Wed) by andrejp (guest, #47396) [Link] (1 responses)

Right. And who would ever need more than 640k lol...

No the point is that there probably is a perf impact once the number goes up, and considering how all these distros seem to like these packs it's not inconceivable that the number does go up. 'mount | wc -l' currently shows *59* on this system - enough that some "work-around" is required if you just want to see the actual disk mounts (read: usefulness). The second point is that bind-mount really isn't the right spot for what MAC does already and (much more) cleanly. The third is that since these app packs are composed by 3rd parties I wouldn't necessarily trust them to do it right, and with potentially not much insight (without digging out source/build files) into how it's actually put together. The fourth I've already pointed out, which is that even if the admin is diligent and updates are applied regularly, the packs might for one reason or another skip updating these dependencies. The fifth I've also pointed out, which is the duplicity of versions of these packs. An old pack might have vulnerable binaries which might conceivably be available as a vector, say by LD_PRELOADing some libs from old/other packs; not that I know of one atm, but still. The sixth is, again, waste of resources by keeping multiple copies; disk is cheap, sure, but I'd prefer not having to constantly up-size partitions. #7 I like a *single* tool on the system to install sw, not mixing apples and oranges; dunno 'bout you but I don't fancy a mixed deb/rpm/snap/flat/whatever system with overlapping namespaces; besides, consider that these packs are a supposed "solution" to the problem of non-unified sw management - devs don't like deb or rpm or don't want to provide both, so they provide a... third... and fourth... and fifth... type, 'coz that's so much "better" and "solves" the problem of too many different pkg managers... right.. so even just listing all the installed software.. umm.. you get the idea. Anyway, #8 taking all of the above in consideration, there are very few salient selling points to these packs; "more secure" certainly isn't one of them - simply unpacking a tgz in /opt/app and providing some standard way of sandboxing ("chroot", except not chroot) would probably be just as good as any app pack out there, if not better, for the simple reason that it'd be standard, inspectable, verifiable and not dependent on the 3rd party to do it right while at the same time keeping various other interfaces clean (mount, df etc)

Linux bind mounts

Posted Mar 19, 2025 16:04 UTC (Wed) by farnz (subscriber, #17727) [Link]

There's no reason why Flatpak couldn't use MAC instead in future - it doesn't, because of the mess that Linux MAC schemes currently are (AppArmor/SELinux/others, some enabled, some force-disabled etc).

And if you genuinely have thousands of user-visible files opened, you need something, somewhere, to track which ones an application currently has access to - otherwise your complaint translates to "I don't like my applications being restricted from sending data they shouldn't have access to out to spy agencies".

Most of your complaints are just about one way to use Flatpaks - Flatpaks can be more secure, thanks to having a standard way of sandboxing and a standard way to transfer the application bundle around, along with isolation between different Flatpaks. And Flatpaks don't have to be "3rd party"; Fedora Flatpaks, for example, are just an automated repackaging of Fedora RPMs with a sandbox policy added to make them a Flatpak.