Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 29, 2016 17:17 UTC (Mon) by tao (subscriber, #17563)
In reply to: Böck: Multiple vulnerabilities in RPM – and a rant by SEJeff
Parent article: Böck: Multiple vulnerabilities in RPM – and a rant

Actually no -- at least never on Debian systems. I dunno about Ubuntu.

I guess you might end up in such situations if you do stuff like forcing installation, installing packages from other distributions manually using dpkg, or something, but other than that things have worked well. Admittedly I've only used Debian since Hamm.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 7:30 UTC (Tue) by nhippi (subscriber, #34640) [Link] (7 responses)

Hamm? get of my lawn you newbie! Debian user since buzz - before apt release-to-release upgrades with dselect where more often miss than hit, with manual repairs needed afterwards. I'd say The current quality reputation for Debian is less thanks to dpkg, but rather thanks to testing distro and release team - evolving sound woody/sarge release.

I've certainly had postinst/postrm scripts leave packages in terrible state, where the only recourse is to edit an exit 0 to scripts under /var/lib/dpkg/info. Sometime due to my own packaging mistakes, sometimes because using unstable. But in less used packages these errors do slip to released packages too. The major failing case is when upstream changes configuration file format and maintainer tries to write a conversion script from old format to new. Maintainer scripts are a major tripwire without an easy recovery path. And one of the reasons I wouldn't recommend distributing third party software in .deb files. It would be less painful if there was a built-in rollback mechanism...

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 13:36 UTC (Tue) by imMute (guest, #96323) [Link] (6 responses)

>It would be less painful if there was a built-in rollback mechanism.

I work at a place where we use debian jessie in a commercial product. I implemented automatic rollbacks by using btrfs snapshots and a wrapper script around apt that ties in to systemd's system-upgrade.target. If the script detects that apt failed for any reason, it rolls back to the snapshot it made at the beginning of the upgrade run. It's an offline upgrade, so two reboots are necessary to go through the process, but it's pretty darn failsafe.

I think part of the reason that getting something like that built in to apt is going to be hard is because everyone wants to do it slightly differently. Does /home get rolled back too? What about logs? Should it depend on what is mounted where? If it does, which mounts get rolled back? Are updates does online or offline? What determines when old snapshots are cleared out? There are plenty of other design decisions that would go into such a feature and there is no One True Answer to them, so a successful product would have to address all of them. :(

It's got some warts but those are mainly due to my inexperience with these kinds of things - I encourage anyone who wants this kind of a system to try to implement it themselves, it's fairly simple to understand in the grand scheme of things.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 13:58 UTC (Tue) by tao (subscriber, #17563) [Link] (4 responses)

No, /home shouldn't get rolled back, since it's a policy violation for packages to change things in /home in the first place (during installation, that is). Nor should things in /root, /opt, /srv, /mnt, or /media.

Logs shouldn't be rolled back (you need to be able to see *why* a rollback was done).

The rest of your questions make sense though.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 16:17 UTC (Tue) by juliank (guest, #45896) [Link] (3 responses)

Of course you have to roll back /opt, third party packages install stuff there.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 18:11 UTC (Tue) by tao (subscriber, #17563) [Link] (2 responses)

That's the point. /opt is for *third party*. Not for things installed with the system package manager.

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 19:06 UTC (Tue) by farnz (subscriber, #17727) [Link]

So if I supply my third party software to you as Debian packages, where should it go? The obvious location is /opt with dependencies on system packages to provide my runtime environment, but you seem to be saying that my choice of package file format affects the acceptable install locations...

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 19:07 UTC (Tue) by juliank (guest, #45896) [Link]

Third party software might (should![1]) be delivered using the same package manager as everything else.

You can also look at the FHS: The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for the local system administrator; packages installing to /opt must install to /opt/<package> or /opt/<provider>.

So, if you want to, you could exclude /opt/{bin,doc,include,info,lib,man} from a rollback as those are reserved for local use, but not the <package> or <provider> subdirectories (practically anything else).

[1] the less package managers on one system, the better

Böck: Multiple vulnerabilities in RPM – and a rant

Posted Aug 30, 2016 16:09 UTC (Tue) by niner (subscriber, #26151) [Link]

The answer should be very obvious: do what other distros like openSUSE have done for quite a while and use snapper.
https://en.opensuse.org/openSUSE:Snapper_Tutorial

That's the nice thing about being behind other distros. You can copy their solutions without having to make the same mistakes in the beginning.