Re: libc6 (security) update does not restart system-services?
On Sun, 20 Apr 2003 00:05:49 +0900
GOTO Masanori <gotom@debian.or.jp> wrote:
> > > > 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?
> >
> > 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.
Yupp...
> 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.
As Bob pointed out in his message, searching for running
programs using the old libraries using lsof and restarting the
corresponding services _automatically_ is currently hardly possible.
IMHO the best practice would be to check if a any version of glibc (or
more generally the library-package just being installed) is installed
already and is to be replaced by the new one. If any running programs
are found, prompt the user an info-message to "make sure to restart
programs/services in order to benefit from the changes".
This would actually only be necessary with either a security update or
with major version changes (such as libc 2.1 -> 2.2).
While the latter is already dealt with by the postinst script, it would
be necessary to know if the update is a simple "new version's
here"-update or if it's a security-related one... That's probabely hard
to decide for Testing and Unstable, I assume, but it is not for the
Stable-tree where generally no updated versions (other than
security-related) are to be installed. So at least for Woody, the
warning message would be appropriate, I think.
> > > > 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).
>
> 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 ?
I was writing 'bout the echo-messages in Woody's glibc-version which
inform the user about restarting services in case of upgrading from 2.1
to 2.2, so I suppose this is a similar case as 2.2 -> 2.3.
Anyway, I did not think of "glibc NSS start problems" ... As I've
already mentioned, I actually don't know enough about the
inside-workings of glibc and the corresponding techniques.
I actually just thought about the memory resident libraries issue, yes.
> 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()".
Thanks for your explanation and the link. I'll check it out as soon as
some spare time drops by... but this might take a while. :)
Thanks too for clearing things up for me (still) definitely being more
of a user than a developer.
Cheers,
Max
--
The first time any man's freedom is trodden on, we're all damaged.
<Cpt. Picard, "The Drumhead", StarTrek TNG>
http://homex.subnet.at/~max/
Reply to: