Flatpaks for Fedora 27

Posted Jul 26, 2017 21:53 UTC (Wed) by DOT (subscriber, #58786)
Parent article: Flatpaks for Fedora 27

I love Flatpaks, since they can be updated reliably without restarting the system, which is a major usability benefit. But it must be possible to improve RPM in such a way that updated packages never require a system restart. I'm thinking that containerization plays a major part in this, since it separates all the different versions of apps and their dependencies.

Flatpaks for Fedora 27

Posted Jul 26, 2017 23:34 UTC (Wed) by tao (subscriber, #17563) [Link] (7 responses)

What software do you typically have trouble updating without restarting your system? I'm fairly sure flatpaks won't solve the need to reboot (or mess around with kpatch) to upgrade your kernel.

Flatpaks for Fedora 27

Posted Jul 27, 2017 9:20 UTC (Thu) by DOT (subscriber, #58786) [Link] (6 responses)

GNOME Software requires a reboot for every update (except Flatpaks), because it can't be guaranteed to work otherwise. Flatpaks do provide that guarantee, because their scope is limited. A consequence of that is that Flatpaks can't update your kernel, for example. So Flatpaks are not a complete solution, but RPM could definitely learn from it.

Flatpaks for Fedora 27

Posted Jul 27, 2017 14:14 UTC (Thu) by lsl (subscriber, #86508) [Link] (5 responses)

Gnome Software might not be able to guarantee it for arbitrary byzantine situations , but I'm 100% confident that I can reliably update a program that's not even running using RPM without rebooting the whole system.

For running programs there's a set of pathological conditions where this might indeed lead to issues. In an ideal world even with these pathological programs the worst case would be some kind of error message about a version mismatch or an unability to parse data files. But lots of software is crap so you might also get to enjoy arbitrary misbehaviour.

Most software doesn't care at all, though. It's mostly the GUI behemoths dlopen'ing random unversioned garbage from disk in response to unpredictable network or user events.

Flatpaks for Fedora 27

Posted Jul 28, 2017 20:27 UTC (Fri) by epa (subscriber, #39769) [Link] (4 responses)

An interesting point for security fixes is that even if the system keeps running fine across the update, you probably need to reboot to be certain the vulnerable code is not still running somewhere. Let's say bash has a security hole, for example. A new package updates /bin/bash and everything stays up. Existing bash processes stay running. But that's the very problem the package update was intended to fix -- a vulnerable older version is still executing.

The unhappy conclusion (unless you want to contemplate some global software-tracking tentacular thingummy that can tell you exactly which current processes were started from which versions of which files) is that in many cases software updates require a reboot on Linux just as much as on other systems.

Flatpaks for Fedora 27

Posted Jul 29, 2017 1:32 UTC (Sat) by lsl (subscriber, #86508) [Link] (2 responses)

That global software-tracking tentacular thingummy isn't far-fetched at all. You can get a reasonable approximation by looking at running processes that have files mapped that no longer exist in the file system (because RPM/dpkg renamed the new version over it). Basically look for DEL in the output of lsof(1) and filter on the paths your programs and libraries tend to live.

Things like DNFs tracer plugin integrate a slightly more advanced play on this into the package management, telling you what (and for many things, how exactly) you need to restart following the transaction.

Flatpaks for Fedora 27

Posted Jul 29, 2017 11:31 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

There are better running process options than just open file tracking; for eg needrestart goes further than just open file tracking by also inspecting programs written in Python/Perl and determining if they have any libraries that were upgraded loaded.

The DNF tracer plugin sounds interesting, do you have a link?

Flatpaks for Fedora 27

Posted Jul 29, 2017 23:45 UTC (Sat) by lsl (subscriber, #86508) [Link]

Sure: https://dnf-plugins-extras.readthedocs.io/en/latest/trace.... There's also a link to the underlying tracer program which is not specific to DNF/Fedora.

Install the python3-dnf-plugin-tracer package to enable it on recent Fedora.

Flatpaks for Fedora 27

Posted Jul 29, 2017 11:28 UTC (Sat) by nix (subscriber, #2304) [Link]

What you say is true for a lot of things that are directly or indirectly network-exposed, but in the bash case you're probably fine, since nearly all bash-related vulnerabilities involve the attacker doing something that spawns a new shell with unexpected capabilities (e.g., in the most famous case, shell functions that should not be there). So in bash's case, unless the hole relates to readline doing something unexpected when faced with hostile input *and* it's paired with a terminal emulator bug that lets the attacker force keyboard input via hostile output, you're probably fairly safe, as these things go. (And even in that case I'd say the terminal emulator bug is the really bad one. If someone can type arbitrary stuff into your shell, they can do bad things even if readline etc are bug-free.)