Fedora 35 To Support Restarting User Services On Package Upgrades

[kreijack]

Sandboxed applications could be limited in scope to access /tmp and certain directories. Example a photo or image editor could be restricted to $HOME/Pictures, a video player or video editor could be restricted to $HOME/Videos and $HOME/Downloads, a music player or music maker could be restricted to $HOME/Music, an office application or text editor could be restricted to $HOME/Documents and $HOME/Downloads.

It could also have a permission popup that asks the user, "Application Foo requests read-only access to /media/, do you wish to grant access"?

So in your setup if you want to see a (temporary) image or a .csv file generated by a python program stored in /tmp you can't ? Sorry, but I need and want more flexibility. I strongly prefer the classic linux distribution model where the packages are a bit older but more trusted (due to the packager review).

[RahulSundaram]

So in your setup if you want to see a (temporary) image or a .csv file generated by a python program stored in /tmp you can't ? Sorry, but I need and want more flexibility.

Sure you can. Flatpak allows an user to configure the sandbox to allow that access if they choose to

https://flathub.org/apps/details/com...chx84.Flatseal

Or in the command line

https://flatpak-testing.readthedocs.io/en/latest/working-with-the-sandbox.html#overriding-sandbox-permissions

[kreijack]

Sure you can. Flatpak allows an user to configure the sandbox to allow that access if they choose to

https://flathub.org/apps/details/com...chx84.Flatseal

Or in the command line

https://flatpak-testing.readthedocs....ox-permissions

I never doubted that I can configure this behavior. The point is not if a flatpack app is capable to access the filesystem. The point is that this is not the default.

It is not the default because the security model of a sandboxed app is based to the prevention of accesses to the filesystem; this means that if this limit is removed, the security model degrades.

Instead the security model of a classic linux distribution is based on the review of the package maintainer (no limits here !).

This and the fact the the each sandboxed app publisher has to care of all app dependencies raises me some doubt about the efficacy of this model.

[RahulSundaram]

I never doubted that I can configure this behavior. The point is not if a flatpack app is capable to access the filesystem. The point is that this is not the default.

There is no single default here. Whoever builds a package gets to determine what they want the access level to be and it is customizable post installation by the user

> Instead the security model of a classic linux distribution is based on the review of the package maintainer (no limits here !).

Not necessarily. An arbitrary package may or may not have additional limitations depending on the service (it is possible for a packager to set limits via the systemd policy or SELinux policy for instance). Distributions don't package everything that a user may use or it may not be the version you want or it may be excluded for licensing reasons and then you are essentially trusting the packager with full root access potentially.

[kreijack]

There is no single default here. Whoever builds a package gets to determine what they want the access level to be and it is customizable post installation by the user

Again, widen the access level decrease the "flatpack" security model.

> Instead the security model of a classic linux distribution is based on the review of the package maintainer (no limits here !).

Not necessarily. An arbitrary package may or may not have additional limitations depending on the service (it is possible for a packager to set limits via the systemd policy or SELinux policy for instance).

Instead adding further limits increase the security of the "distribution model".

The difference is the starting point. The app model towards to the model of the phones "store", where there is the distributor who is not interested in entering in the details of the app. So to guarantee a sufficient level of security each app is sandboxed. Widen the access level decrease the security.

The "classic linux distribution model", is based on the fact the package maintainer (who is different from the developers) enters in the details of the application and can do a deeper review. Furthermore it is possible for certain type of program (typically the server) reduce the access level increasing the security.

Distributions don't package everything that a user may use or it may not be the version you want or it may be excluded for licensing reasons and then you are essentially trusting the packager with full root access potentially.

On this point I agree. But usually this kind of situation are exception than the rule...

[RahulSundaram]

The "classic linux distribution model", is based on the fact the package maintainer (who is different from the developers) enters in the details of the application and can do a deeper review.

You are assuming a lot here. a) upstream isn't packaging it for the distro themselves b) the reviewer is capable of reviewing the security details of the application equivalent or better than the upstream developers c) human review even if well intended can catch security issues d) flatpak's aren't going through a review process

As someone who has done packaging work for hundreds of official packages for over a decade, I can say that all these assumptions are inaccurate.

> On this point I agree. But usually this kind of situation are exception than the rule...

No. Not at all. It is increasingly the case that a common set of core packages come from the distro. Everything else comes from a third party including language specific package managers, containers, third party repos and so forth.

[andyprough]

These claims are just false.

This change is just a scriptlet that optionally allows a package to set a service to be restarted automatically after an update for user services (system services already had that capability a long time back). User services are not that common and most packages that use user services still won't use it leaving it to the user to restart the user services when they want to. Neither RPM or systemd required you to restart a computer after an update before or after the change.

Could be untrue today. Wasn't untrue during any of the 20 years I ran rpm based distros for my business, including Fedora in about 2015. If rpm has suddenly become a modern and useful protocol since September 2019 when I moved to deb based distros, then more power to you. There was never a time during my 20 years with rpm when you could do anything but handle updates with extreme delicacy. Failing to restart after an update of any system package or library was just begging for system breakage. There was never a time when we weren't admonished by the various distro forum administrators to restart after every update which included a system library or system package or service or we would risk breakage. If Fedora has fixed this problem since 2015 or rpm in general has solved it since September 2019, then you have my congratulations.

[RahulSundaram]

Could be untrue today. Wasn't untrue during any of the 20 years I ran rpm based distros for my business, including Fedora in about 2015

Again, this is categorically untrue. There was never a point at any given time in any of Fedora's history that users have to restart a computer for a simple update. This is a nonsensical claim given that millions of instances of Fedora and Fedora derivatives including RHEL/CentOS have been used for enterprise systems sometimes running for months without any restarts in between. Packaging format has no impact at all on this.

[kreijack]

You are assuming a lot here. a) upstream isn't packaging it for the distro themselves

Even tough this is possible, is not the most frequent cases. Even if the author provides a .spec file and/or a debian/ tree, the packager check and change it according to its own experience.

b) the reviewer is capable of reviewing the security details of the application equivalent or better than the upstream developers
c) human review even if well intended can catch security issues
d) flatpak's aren't going through a review process

The point is that the flatpack publisher have to review its own software and ITS DEPENDENCIES. This is the problem.
The packager have to review only the software itself.

This is particular relevant when a dependency needs a security update:
- in the "classic model", the dependency packager has to updated this single package
- in the flat pack model, each publisher has to care that its own software and all its dependencies are updated..

The point here is that in the flatpack model each publisher has to care a lot more than its specific app. I am not worried about the biggest projects like firefox and/or libreoffice where there is knowledge and accountability (and manpower); I am worried about the little projects which require dependencies with security implication (like libtsl or whatever is its name).

In the "classic model", typically who is charge of packages like libtsl are conscious of its security implication. it is impossible that all the publisher of all flatpack apss have the same level of awareness.

As someone who has done packaging work for hundreds of official packages for over a decade, I can say that all these assumptions are inaccurate.

> On this point I agree. But usually this kind of situation are exception than the rule...

No. Not at all. It is increasingly the case that a common set of core packages come from the distro. Everything else comes from a third party including language specific package managers, containers, third party repos and so forth.

As debian user, there are very few packages which aren't included. Instead the last time I used Ubuntu I noticed that the gui bring the user to use "flatpack" apps. So I quickly de-installed it.

Instead there is application where a flatpack model could make sense. I am thinking to something like "Oracle db". But this is a specific case.

[andyprough]

Again, this is categorically untrue. There was never a point at any given time in any of Fedora's history that users have to restart a computer for a simple update. This is a nonsensical claim given that millions of instances of Fedora and Fedora derivatives including RHEL/CentOS have been used for enterprise systems sometimes running for months without any restarts in between. Packaging format has no impact at all on this.

Oh really? October 5, 2016: https://lwn.net/Articles/702629/

But there is a misconception that dnf update completely updates the system without a reboot, Peter Larsen said:

People think that "yum/dnf update" leaves their system in a new updated stage. But it doesn't (completely). It never has. Only after a reboot are all your patches applied and active. Existing/running processes are rarely if ever reloaded. So when you update libraries, kernels etc. your system will keep running with the old versions of those libraries loaded. [...]The only real complete update you can do is one that does a full reboot. We do have a few tricks with DNF which will attempt to let you know what needs restarting. But you'll find that a good part of our updates requires a restart of most if not all your system, in order for the updates to become fully active.

Perhaps partly because it normally works just fine, it is surprising to find that dnf update is not really a supported way to update a Fedora system—even from a virtual terminal outside of the desktop. Many will probably keep on doing it, but once in a while may get bitten. As Williamson put it: "It works fine all the time until it doesn't, and then you're left with a pile of broken bits that you get to spend all afternoon fixing."

You were saying my memory was faulty or something? I know I'm old, but I'm not quite that old.