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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
