On Sun, 27 Aug 2017 at 10:45:30 +0100, Barak A. Pearlmutter wrote: > If I might ask, how is this currently handled with > unattended-upgrades? [...] Just leaving the system vulnerable > until a coincidental reboot doesn't seem appropriate.
It is (or should be) handled the same way as upgrading the kernel, which cannot be replaced in-place; display managers like gdm, which cannot be replaced in-place without disrupting user sessions; and in general anything that isn't conveniently restartable by a systemd unit or init script, like user sessions and user-provided code. dbus.postinst touches /var/run/reboot-required, which is apparently used by unattended-upgrades to detect that a reboot is needed (/etc/kernel/postinst.d/unattended-upgrades does the same thing). If there are other APIs for notifying the rest of the system that a reboot is needed, I'd be happy to add them - please file a wishlist bug with a link to their API documentation. #867263 suggests that there might be some other API that provides more information than "a reboot is needed", but doesn't specify who consumes that information or what its "API" is, so is not currently actionable. In general, unattended upgrade infrastructure can't know for sure that a reboot isn't needed. If there's a bad enough security vulnerability to be seriously concerned about it, the safe thing to do is to reboot the system, to ensure that there can't be any lurking libraries or configurations from before the upgrade. I know this is disruptive, particularly on systems that have been designed with the assumption that reboots don't often happen, but it's also the only way to be sure; and system designs have to be able to cope with semi-frequent reboots *anyway*, because the kernel semi-frequently has exploitable vulnerabilities fixed. This is one of the main reasons that non-apt OS deployment mechanisms like OSTree require a reboot to apply an upgrade. The other is that their designers want to perform an atomic cut-over from one good/consistent state to another, eliminating the transitional undefined/broken state that occurs during apt/rpm/etc. upgrades, which could cause incorrect behaviour when related code runs during the upgrade or if the upgrade is interrupted by a power failure, an unexpected reboot or sysadmin action. smcv