On Sun, 17.06.12 10:53, Richard W.M. Jones (rjones@xxxxxxxxxx) wrote: > On Sat, Jun 16, 2012 at 03:06:10PM +0200, Ralf Ertzinger wrote: > > Hi. > > > > On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote > > > > > One of the most inportant advance of Linux over Windows is the > > > fact, that there are only a few situations - like kernel updates - > > > which requires a reboot of your system. > > > > Linux has, in principle, the same problem as Windows, that while > > you can replace files that are in use running processes will (of course) > > not pick up the changes until restarted. Most daemons do so when updated > > themselves, but, for example, updating zlib because of an exploit will > > not restart all daemons using the exploitable library, so unless the > > admin restarts those manually or the system is rebooted you might > > still be vulnerable. > > So this is a problem that needs to be solved, but does it require a > reboot? Not really ... it's possible to list all processes using > zlib, convert that back into a list of packages, then instruct those > packages to restart themselves. Job done, BETTER than Windows / OS X. Well, if you are referring to doing "lsof" do figure out mapped libraries, than this is simply not sufficient, since there are many more ways how pieces of code we run interface than just shared library interfaces. Sure, with lsof you can find link time shared libs deps of running core. But there are so much other deps you'd need to follow to fully determine the set of things to restart: local socket protocols, bus interfaces or just data files (in /usr/share or so) that are used by code, that when upgraded also need its users restarted. And then there is the huge amount of code we cannot restart at all within a running system. Like the kernel, or dbus. But even more this is true for user applications: how would you go forward and ensure that firefox is restarted if the SSL libs have a vulnerability? And then, upgrades cannot be atomic, that means that there's a time where a process has not been restarted yet where it partially uses old deps/data files and where it partially uses new deps/data files, which is just doomed to go wrong. I mean, have you ever tried to upgrade firefox while running firefox? If you did, you know how awfully wrong that goes... [1] So, you have three problems: a) you cannot safely determine what to restart. b) you cannot restart many components of the OS at all c) upgrades cannot be atomic. Altogether this means, that in-system updates are something that is highly likely to break, and it does all the time. Sure, often enough you get away with doing in-system upgrades, but if we write our programs in a way that things work corretly only "often enough", then we'd bad bad programmers. But anyway, nobody is taking "yum upgrade" away from you. It makes a ton of sense to use this, especially if you are a developer. I for one will always continue to use it, simply because I can deal with the fallout. But that doesn't mean we should implement the safe, technically correct way for the majority of users. Lennart Footnotes: [1] it's actually fun to try, in many cases firefox throws a tonload of JS errors, and even refuses to be shut down at all, unless SIGKILL is used... -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
