Schedule for Monday's FESCo Meeting (2012-06-18)

[Lennart Poettering]

On Sun, 17.06.12 10:53, Richard W.M. Jones (rjones at redhat.com) 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.