Re: libc6 (security) update does not restart system-services?
At Fri, 18 Apr 2003 17:24:17 +0200,
Markus Amersdorfer wrote:
> On Fri, 18 Apr 2003 13:06:07 +0900
> GOTO Masanori <gotom@debian.or.jp> wrote:
> > > - /var/lib/dpkg/info/libc6.postinst checks for "$1" ==
> > > "configure"
> > > (which is the case when updating, isn't it?). If true it
> > > afterwards checks if "$2" is lower than "2.1.95-1" (I assume this
> > > corresponds to the previously installed version) and _only if this
> > > the case_ it restarts most of the services.
> > >
> > > Woody comes with libc6 2.2.5-11.5, so the section about restarting
> > > services is never reached.
> > >
> > > This leaves the machine vulnerable as all services use the old
> > > library until restarted.
> > >
> > > Shouldn't the services be restarted when installing a new
> > > libc-version? What reasons would there be not to restart services?
> >
> > Restarting services is needed only once: upgrading from 2.2.x to
> > 2.3.x. The reason is simple. NSS (Name Service Switch) is much
> > changed, and it becomes incompatible between 2.2 and 2.3.
> >
> > So if you use woody server, not sarge, then you have no need to
> > restart services. If you use libc6 2.2.x, it's not related.
>
> So restarting services is necessary when upgrading from 2.2.x to 2.3.x
> to make sure everything works fine (as e.g. the example of xdm you
> mention below). When staying with basically the same version and
> "simply" doing a security-update, there are no compatability-problems,
> of course, so everything keeps running smoothly.
>
> But my concern is that running programs such as system services use the
> old libraries instead of the new one as long as they continue running,
> don't they? If they do the security bug is still exploitable though the
> new libraries are already installed on the system.
Yes, right, good point. This is not only glibc issue; this problem
affects all library packages. The old libraries are remove-pending
state on the file system, and reside in applications.
So everytime we have to restart all binaries which use a library
involving security-problem. In additionm this problem affects not
only debian packages, but user-built binaries.
I have to warn all users who believe that we needs only "apt-get
upgrade, yeah, that's all folks!" concept. It's not true for this
library upgrade issue.
From our glibc upgrade experience, it's difficult to restart packages
which have specific problem automatically... The simple method to
detect old libraries are to use lsof, so debian package system can
warn for users "there are old libraries which has security problem, so
you should restart these binaries". I don't know there is good way to
fix this problem.
> > > If everything _is_ designed not to restart the services, I suppose
> > > telling the users to take care of that theirselves would be a good
> > > idea for example using a simple "echo" in the post-install script
> > > (or similar).
> >
> > The restarting message is not sufficient for you?
>
> Of course, but the message is only shown if the services _are_ to be
> restarted (which is only when doing a major version update).
> Services are not restarted by the security update though I think they
> should be (as stated above).
>
> If I'm wrong, please correct me. :)
I think you confuse two issue. One is generic problem as I write
above (memory resident libraries issue). Another is glibc NSS start
problem as I write below.
Or did you point the messages which are not appeared in
libc6.postinst when you upgraded from 2.2 to 2.3 ?
> > BTW, I plan to dupload 2.3.1-17 that has preinst message to choose
> > libc6 upgrade or not. It's needed because for example xdm cannot
> > authenticate after installing libc6, but we cannot restart xdm with
> > postinst automatically (user's X11 session is destroyed). I add
> > messages in next 2.3.1-17 as they have to restart xdm with their hand.
> > If you have requests about restarting messages, please tell me.
>
> Though I don't know enough about the detailed processes running inside
> the library packages: Sounds great. :)
> Perhaps it's possible to delay installation of the libraries until the
> next reboot? The user would have the chance to have the libraries
> installed "instantly" (which would break xdm), "automatically at the
> next reboot" (is that what you meant above?) or "not at all" at the
> moment (though I currently can't think of a good reason why to do that).
You said about "generic problem (memory resident libraries issue)",
and I don't think it should be. Delay installation everytime requires
system reboot. But some users know it needs only application restart.
In addition, it's only applied in upgrade between the same library
version. If this delayed installation is introduced for glibc, then
upgrade from woody to sarge breaks all binaries. Sarge packages
depends on glibc 2.3.x, and it can't run under woody's glibc 2.2.5
environment. If you run sarge/sid /bin/ls under woody glibc 2.2.5,
then you get error:
/bin/ls: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /bin/ls)
OK, now start to say about "glibc NSS start problem". The reason why
glibc needs to restart all NSS authentication services was written in
my (a bit long) mail:
http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html
The problem is "dlopen()". Unpacking 2.3.x libraries affects all NSS
applications not to authenticate immediately. We have to restart all
services because dlopen() interface is changed between 2.2 and 2.3.
Moreover, you may be surprised that debian has never guaranteed
anytime that libraries using dlopen() do not keep its compatibility.
This is the potentially dlopen() concept limitation. This problem
brings up because glibc affects so many packages and binaries this
problem.
dlopen() is broken, dlopen() has also problems for example handling
C++ mangled name (there is a technique to avoid, though), however we
have no nice method to open dynamic libraries in the user application.
Regards,
-- gotom
Reply to: