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
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.