Re: F27 System Wide Change: Graphical Applications as Flatpaks
Colin Walters wrote:
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.
But both these points are not worth throwing away the efficiency of shared
dependencies!
Kevin Kofler