Hi, On Fri, Jul 14, 2017, at 05:52 PM, Andrew Lutomirski wrote: > I don't see the problem. The runtime could be all of /use and the app > could be a symlink living in /app that points at /usr. The latter > could be created on the fly in a tmpfs. You're right; however, there are two other aspects to this. First, RPMs (as we use them) are designed for a single merged /usr, and their %post scripts run with full CAP_SYS_ADMIN privileges. This means if one wants to install any 3rd party apps, any sandboxing at runtime is...well, useful, but there's a rather gaping hole if the app is malicious, or the app provider is compromised. This argument also applies to distributions I think as well - it will improve security to ensure that many apps and shared libraries (that aren't used in host systems) *never* have CAP_SYS_ADMIN. Second, to rephrase Richard's reply, the code+process lifecycle binding is significantly simplifed in the flatpak model. It by default implements a model where updates don't delete files underneath running apps. This has never (AFAIK) been solved in the traditional package manager model, and though I could imagine doing so, you'd really end up with separate filesystem trees, whether those are explicit or implicit. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
