flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Posted Mar 19, 2025 11:33 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
Her name is Performance. If you find her please return her safely.
Unfortunately I can't offer any financial reward to the finder, but I'll let the finder keep her as compensation.
Posted Mar 19, 2025 12:01 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (10 responses)
Posted Mar 19, 2025 12:05 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
An extra layer of indirection can solve all manner of problems, except the problem of too many layers of indirection.
Cheers,
Posted Mar 19, 2025 12:09 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Posted Mar 19, 2025 13:53 UTC (Wed)
by andrejp (guest, #47396)
[Link] (7 responses)
Posted Mar 19, 2025 13:58 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (6 responses)
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?
Posted Mar 19, 2025 14:24 UTC (Wed)
by andrejp (guest, #47396)
[Link] (1 responses)
Really? Well that's new lol. Lemme check.
# cd /tmp
Posted Mar 19, 2025 14:40 UTC (Wed)
by andrejp (guest, #47396)
[Link]
Posted Mar 19, 2025 14:33 UTC (Wed)
by andrejp (guest, #47396)
[Link] (3 responses)
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 :)
Posted Mar 19, 2025 14:49 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
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?
Posted Mar 19, 2025 15:49 UTC (Wed)
by andrejp (guest, #47396)
[Link] (1 responses)
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)
Posted Mar 19, 2025 16:04 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
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.
How, exactly, does asking the system to bind mount a directory chosen by the user into the mount namespace your process is using, hurt performance?
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Wol
Except that this isn't a layer of indirection, as implemented in the Linux kernel - it causes the mount point (the user's chosen directory or file) to directly point to the right place in the underlying filesystem structures. You pay a bigger price when the kernel does UID/GID permissions checks on open.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
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?
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.
Linux bind mounts
Linux bind mounts
# 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
Linux bind mounts
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.
Linux bind mounts
Linux bind mounts
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).
Linux bind mounts