flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Posted Mar 15, 2025 1:41 UTC (Sat) by andrejp (guest, #47396)Parent article: Fedora discusses Flatpak priorities
The claim that it's somehow "safer" is also false. Want to sandbox the app? Sandbox it in the system, not in the package.
The very reason linux chose centralized distribution of software ("distros") is that the app software is separate from the dependencies. Ergo if a dependency breaks or has security issues, upgrading the dependencies in the system can fix it. Meaning a distro can fix issues that the app devs either can't or won't, and distros need not wait for upstream to update dependencies in the package, which they might - or might not - after and if they release a new version. Doing so mid-cycle is unlikely as it means more work for them. And until they do, the app is broken/vulnerable, together with the system that the app is installed on - it's a pretty obvious vector of attack, same as it is on wintendo.
Hence a centralized repo is *safer* than an app packaging all the dependencies. It's the very reason *why* distros even exist and *why* distros don't (didn't) want users to install apps together with all the dependencies in a single package. It's also part of the reason *why* linux distros are (were) much more secure than wintendo app distribution.
But now I read how "flatpacks" and "snaps" are somehow better. Better how? What security are you talking about? If an app needs to interoperate with the rest of the system, don't sandbox it. Doing it anyway will probably break it in subtle ways. And if an app requires sandboxing, do it in the *system*, not the package. Why are you even relying on 3rd party package and packager to do it right? They might not even have the skill to do it, or the will, or the resources. They might not even care, or they might break it intentionally. It's stupid beyond explanation, yet y'all are telling me that it's somehow "more secure"?
And don't force multiple copies of packages on the system. Flatpacks and snaps are fscking abominations on the system. Run "snap list --all" and there's two copies of *everything*. Just in case a user might want to... what? Uninstall the last version and install/use the previous one? 'Cause otherwise she can't do that? GTFO. Run "mount" and there's tens of mounts, to the point that the output is basically useless unless what you want to see is the list of installed abominations. Same for df, with systemT ('T' as in "trash") polluting 'df' output with "credentials" and what not. How are "credentials" a fscking block device? And if they're not, why the fsck are they polluting df space to where it's about as useful as "mount" - which is not at all?
I'd uninstall Lennart if I could, together will all the flatfootedpacks and snaps that I'd happily snap a big fat stick on beating them off the system. Heck I'd snap as many sticks as it would take to where not one "snap" or "flatpack" remains. Alas, most - if not all "distros" (as in short for "centralized software distribution repository") these days seem to prefer the wintendo way. Which makes the purpose of these distros even existing questionable. What do you need a "distro" for if every 3rd party package copies half the system with it as bundled dependencies? Multiple times?
Posted Mar 15, 2025 3:19 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (37 responses)
The problem is, it's not binary. You still want your app to be able to read the files, just not arbitrary files, but the ones that users select.
> Doing it anyway will probably break it in subtle ways. And if an app requires sandboxing, do it in the *system*, not the package.
Flatpaks don't sandbox themselves, the system does it.
Posted Mar 18, 2025 2:33 UTC (Tue)
by andrejp (guest, #47396)
[Link] (36 responses)
Exactly the point I was making.
> Flatpaks don't sandbox themselves, the system does it.
Semantics. Tautology. The "sandbox" (access) border is where it is. "Packs" put it at "package" border. But your own example says you want more flexibility than that. Hence the argument: if an app needs to interoperate with the rest of the system ("the files that users select"), don't sandbox it (at the "package" level). Doing so anyway will just break the app in subtle ways (as in "you want users to select files" which are outside the scope of the package sandbox). Hence the second half of the argument: proper place to do it is "in the system" (fs or whatever subsystem is relevant).
That being the case (that the proper way is to do it "in the system" and not "in the package"), how are these packs better? What security are you talking about? It's just a fixed sandbox border that is itself a problem if the app needs to interoperate with the rest of the system. Which most generally do. And to enable this "interoperability with the reset of the system", the "pack sandbox" needs to be worked around and circumvented, and the app then sandboxed again at some other ("the system") level ("to be able to read the files, just not arbitrary files, but the ones that users select"). Which makes the fixed sandbox at the package level not only redundant, but problematic.
Posted Mar 18, 2025 2:46 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (35 responses)
Are you an LLM?
Flatpacks provide a way to limit the access to the system via portals, sandboxing all other ways of access: https://docs.flatpak.org/en/latest/portal-api-reference.html
Posted Mar 18, 2025 2:59 UTC (Tue)
by andrejp (guest, #47396)
[Link]
Puhlese...
You should probably ask yourself that, considering your generic "answer".
Posted Mar 18, 2025 3:35 UTC (Tue)
by andrejp (guest, #47396)
[Link]
In other words, "here's how you can circumvent our sandbox so you can implement a different one - we'll even provide you with tools, it's just another API for the API, to supplement the original API, and it all works on the same system-level APIs that you can use without ever even touching our APIs. but hey, it's all free, so why complain and object, right?"
Like a free bullet in the head. No reason why anyone would ever object or complain about anything, as long as it's free.
LOL.
Don't worry, I've learned my lesson. I'll go back to just reading, same as I've been doing for the last 30 years.
Posted Mar 18, 2025 8:53 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (32 responses)
Posted Mar 18, 2025 9:29 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (16 responses)
How would you solve this?
Posted Mar 18, 2025 9:35 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (15 responses)
Posted Mar 18, 2025 9:40 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (14 responses)
If you think that what Flatpak does is "a way to sandbox, just not a really comprehensive or good one", then *what exactly* would be a comprehensive or a good one instead?
Posted Mar 18, 2025 9:58 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
1. The "files referencing other files" issue I've already mentioned
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.
Posted Mar 18, 2025 10:18 UTC (Tue)
by intelfx (subscriber, #130118)
[Link]
> 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?
Posted Mar 18, 2025 9:58 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (11 responses)
If by "fundamental" you mean "a real pain in the proverbial for the user", then I think it is. Unless you comprehensively think through all use-case scenarios (which imnsho most developers are cognitively incapable of doing) you are going to have quite a horde of users complaining "my use case is broken".
For example, something I do, for very simple and good reasons, is have a humungous load of hard links all over my system. Less so now, but my wife and I took loads of photos (my camera tells me it can only store 1100 photos on the 100GB of flash cards in it ...) so they were all stored in a central area, owned by root (to prevent accidental damage), and linked everywhere they were required. Niche usage, sure, but most apps don't have a clue about that sort of setup. And there'll be plenty of other niche cases out there ...
Cheers,
Posted Mar 18, 2025 10:06 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (10 responses)
It might be an important problem, but I'm almost certain it's not a fundamental one.
Posted Mar 19, 2025 6:26 UTC (Wed)
by andrejp (guest, #47396)
[Link] (9 responses)
It's akin to scratching your ass if your arm itches. It might feel good, but won't actually do anything about the itch. Alas the "Lennarts" of the world insist that "this isn't the itch you're looking for" (waving hand) and would instead provide users with a fat sticker to put over the arm, claiming that that will somehow fix or prevent any and all itches. Which in theory sounds fine until the arm starts to itch anyway. For which Lennarts provide more, bigger and fatter stickers, along with a stick as a "free" bonus (so don't complain, 'coz it's free) so you can scratch your ass more conveniently.
Check the internet. Or at least LWN. Seems like a whole lot of people with itches they can't scratch, 'coz Lennart and his one-fix-for-all stickers.
The solution ofc is to uninstall Lennart, along with packs that fall flat, snaps that mostly snap the system's resources, and systemT (T as in "trash"). Then the itch can be scratched by the user in the proper place. And if you want to feel good too, you can also scratch your ass, even if it doesn't itch. All without Lennart's "free" sticks and stickers.
It's pretty simple actually. A system-wide MAC can do it. It's helpful if a systems integrator ("distro") - and /not/ the 3rd party that provides the app - provides the default MAC sandbox for the app(s), but not strictly required. Then the *user* can add the required permissions/exceptions for *his* use case. All "in the system" (and not "in the app package"). No Lennart required.
Posted Mar 19, 2025 6:42 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (6 responses)
Posted Mar 19, 2025 9:42 UTC (Wed)
by andrejp (guest, #47396)
[Link] (5 responses)
That I loathe Lennart's "solutions" that much is obvious. Hardly "hate speech" though, unless you define "hate speech" as "you disagree with my solutions" == "you hate me".
Or perhaps you equate my using "Lennarts of the world" with "hating Lennart"? Well I don't "hate Lennart", but I do use the idiom a bit akin to "Karens of the world". Perhaps it's not "fair" to Lennart, so let me give an example.
Suppose someone was to park a proverbial truck in your living room as a "solution". Would that make you happy? No? What if that someone then told you that the truck solves *his* problem superbly and that if you don't like the truck, that is *your* problem, so *you* should "work around" the truck (ie. "WONTFIX")? No? You'd still protest? Darn. I'm sure though that if the proverbial truck displayed a big red sign in the windshield that said "truck tainted 'coz living room too small", that would definitely make you love the truck. Fo' sure. Or else you're just a "hater" lol. Especially if you suggested in no uncertain terms to remove the fscking truck - that would no doubt be a big, "uncivilized" no-no.
Right?
So perhaps you can understand what I mean by "Lennarts of the world": the types that park proverbial trucks in other peoples' living rooms and expect other people to "work around" the truck while at the same time waving off and labeling any criticisms or objections or suggestions to remove the truck as "hate speech" and "personal attacks". It *is* just a truck, right? And it's not even that big - it didn't even fill the *whole* room, you can still walk around it, and it comes with a built-in kitchen sink too! You've just saved space in the kitchen! And best of all, "it's free"! So why so much "hate"?
Or, perhaps you just disagree with me seeing LP as a "Lennart" per example above.
Well okay, that's perfectly fine. I'm sure a number of other readers would possibly - even probably - agree with my own view. YMMV.
Posted Mar 19, 2025 9:58 UTC (Wed)
by andrejp (guest, #47396)
[Link] (4 responses)
I mean... "GRUB tries to do too much, and most of those things are a mistake, he said."
Posted Mar 19, 2025 13:07 UTC (Wed)
by daroc (editor, #160859)
[Link] (3 responses)
Please stop this thread of conversion here, and be less vitriolic in your future comments.
Posted Mar 21, 2025 14:52 UTC (Fri)
by andrejp (guest, #47396)
[Link] (2 responses)
I don't think you see how rude and personally insulting *that* is.
But then again, it's part of the same reason why Lennart has been getting all that flak: snubbing and hand-waving off anyone that happens to not quite fit into the crowd of cheerleaders, or even outright disagrees with the crap that's being pushed on users.
I understand - you don't like words like ass, shit, crap, fuck and so on and so forth. But gee, see what happens if I first snub and hand-wave you off (like I just did - deliberately, not to offend or incite you, but in order to demonstrate a point), then label you with some juicy and colorful labels ("you're 'hating me'", "your comment is full of 'vitriol'", "I find your comment to be 'personally insulting'"). First you're going to "warn" me "politely" (check). That failing, you're going to use "stronger" words ("hate speech", check). That failing, you're going to propose "uninstalling" this uid, 'coz "he's parking 'trucks' (ass, shit, fuck, crap) into the 'living room' (this comment section)" (pending, probably being considered). That still not having the desired effect (new uid), your next step is probably going to be to suggest "uninstalling" the IP this comment has come from. Then probably "uninstalling" by "legal action". And so on.
In other words, you'll want "the *whole* 'truck' out of your fscking 'living room'".
To which my response to you is, again deliberately, in order to demonstrate the point: "please stop with the hate speech", "please stop personally insulting me" and "be less vitriolic in your future comments".
Posted Mar 21, 2025 15:14 UTC (Fri)
by jzb (editor, #7867)
[Link]
OK. Time to end this thread. To be very clear—the comment section is not the place for people to snipe at one another. It's quite OK to have disagreements on topics, but nobody needs or wants to read two or more commenters just arguing with each other. Stop here.
Posted Mar 21, 2025 15:15 UTC (Fri)
by andrejp (guest, #47396)
[Link]
I understand. I apologize for the inconvenience.
Posted Mar 19, 2025 7:01 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Posted Mar 19, 2025 9:43 UTC (Wed)
by andrejp (guest, #47396)
[Link]
Posted Mar 18, 2025 21:36 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
Such as the all-important list of the greatest titles stored in `/etc/shadow`. At some point, these kinds of features need to just go away as fundamentally insecure. As a compromise, you might be able to refer to files in the same directory and its subdirectories.
Posted Mar 19, 2025 10:16 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (13 responses)
Posted Mar 19, 2025 11:33 UTC (Wed)
by andrejp (guest, #47396)
[Link] (11 responses)
Her name is Performance. If you find her please return her safely.
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.
Posted Mar 19, 2025 17:31 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
> Flatpacks provide a way to limit the access to the system via portals, sandboxing all other ways of access:
Turing test fail lol.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
And honestly - the IQ test was real easy.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
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)
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Wol
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
No, wait, that wasn't my comment. Hm.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Stop now
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Hm. No that's the wrong quote.
So long, and thanks for all the fish?
Lol.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Note that the portal API already lets you open a directory, instead of a file - you can ask for the directory representing the root of the Bluray instead of the index file, and you will be granted access to that entire directory and all its subdirectories. This is plenty for a Bluray player, but problematic if you want access to /etc/shadow.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Unfortunately I can't offer any financial reward to the finder, but I'll let the finder keep her as compensation.
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
flatpacks falling flat, packing bugs, snaps snapping resources, both suck