I’ve always learned there isn’t a need to restart a Linux system when a security update is done, only the relevant services.
Today I received an update to glib (CVE-2008-4316). Which things do I need to restart? :\
Since zypper doesn’t mention anything about this, my guess is most people just apply the patch and go on (keeping the vulnerable library versions in memory?)
Any process that uses glib. You can get a process list by
lsof | grep -w libglib
Thanks 
that seams to be what I’m looking for.
On a related note, I think it would be cool if zypper automatically mentioned which apps need a restart…
zypper or any other program can not accurately determine that. A security update may be just updating a configuration file that may have been already read in by a running program to create some vulnerable memory structure.
I think, yast advises you to re-boot only when kernel or any loaded driver is updated.
I’d say something is better then nothing… Users are now left in the dark believing that running the update applet fixed their security problems… :\
I think, yast advises you to re-boot only when kernel or any loaded driver is updated.
Correct. and for a good reason: if you plugin a new device, the kernel can’t find the old modules anymore in /lib/modules/…
If an update changes the kernel, the user is notified to restart.
If an update changes a service, that service is restarted, This may however leave running instances of the service still using the old code. But it’s not a good idea to kill those automatically. Imagine an update killing your ssh session from a remote location.
If an update changes a dynamic library, apps that are still using the old library will continue to link to the old, deleted library. Again, it’s not desirable to kill those automatically, it may be too disruptive.
If an update changes an app, then running instances may be affected. E.g. the last Firefox update made the running browser window unusable because xulrunner changed.
So there is still a window of vulnerability. But certainly it’s better than before the update. It’s a tradeoff between security and disruptiveness. Restarting after every update should cover the situation, but that is too drastic. That’s is why some updates have a message for the user. In the case of glib, this was a widely used library so the user was asked to exercise some judgement.
Most desktop users will be shutting down after the current session. Server admins are supposed to have enough brains to decide what to do.
Perhaps some day someone will write a program to scan the processes and loaded dynamic libraries and suggest to the user what to do. This could be put in the post-install action of the package. Might make a nice software project for somebody.
hehe what about suspend/hibernate.
Correct me if I’m wrong but doesn’t the above reinstate the old libs and apps? If so I wonder how many people are oblivious to that.
I think your computer has got to be alive to receive an update and as far as I know there is only one suspended image, the last one, which is deactivated when the resume is successful.
I realised it had to be live to update.
What I was asking/presuming doesn’t it keep the old libs, in the image? So without the reboot it won’t use the new libs/apps any way. i.e you resume the old image without the updates as such
More a question than a know, I’m still way to hazy about this resume suspend stuff.
Well a resume isn’t a time machine. You wouldn’t want to be transported back to a state where your edits are backed out. It just does what it says, it resumes things from the point of the suspend. The suspend takes a snapshot at the point you hit the sleep button. When you resume, the flag is cleared and the image cannot be used to resume again, preventing you from being transported back in time. The resume partition is usually the swap partition so it might be overwritten with use anyway.
So these people that are suspending/hibernating aren’t really getting the security updates? Which is what I was getting at. I suspect a few laptop owners resort to them frequently.
Still not really sure on the answer, with your answer.
They’ll get them the next time they resume the machine, provided it’s on long enough for the updater applet to run and online of course.
Look at it this way, a suspended machine is no different from an off machine, only it has a fast way of getting back to the state it was in before the shutdown.
But my understanding is it is reinstating the libs and apps too, which you sort of pointed out about not reverting to an old edit.
Surely this would mean my app wouldn’t open the same if it had changed the libs/app. Surely it is the same as the above not wanting to reboot.
My understanding is we’re grabbing the ram with hibernating dropping that to swap. When reinstating we drop the swap back into ram am I wrong then?
It’s resumed from the point of the suspend. It’s not resumed at any old point. If the updates had already been applied, they would be there. If you had not applied any updates before suspending, then it’s ready for updates. That’s why I said it’s no different from the case of turning off your machine, package-wise. As for what happens in RAM, it’s like you resumed, as advertised. It’s not a shutdown, so you could still be using the old deleted libraries, but only for running processes, not new ones yet to be started. The advice that came with glib said restart the machine, not suspend and resume the machine.
If I pull the power cord from my machine and go on holiday for 3 months, obviously when I turn the machine back on it’s going to be 3 months behind in updates. Perhaps the updater applet should yell “Waitaminute waitaminute, don’t do anything, lemme update you first” :).
Looking further ahead, one could imagine a really smart updater that would say “Hang on, I see you are using SUSE 9.3. This is out of support. I will shut you down now.” Then we don’t have to advise people who try to use old distros not to do so. This will really be a hit with the users. Not! lol!
But your point about snapshots is valid in the case of virtual machines like VirtualBox where one can take snapshots. If you resume from an old snapshot, obviously it’s not going to have updates since you’re going back in time. And the irony is that this is promoted as a way to get back to a pre-virus state for Windows. 
Thank you for the time and the explanation.
I’m just terrible for wanting to know how it all works and been fighting the Suspend/Hibernate battle today so was a little fresh(I won’t bring hal into it).