Anwender-Informationen zur UNIX glibc

Die C-Library (Bibliothek) gehört zu den wichtigsten Bestandteilen eines jeden UNIX-Systems, denn sie ist mitverantwortlich für das reibungslose Zusammenspiel zwischen Anwendung und Serverprozess.


Im Folgenden finden Sie einige Hinweise und Hintergrundinformationen, in denen wir kurz skizzieren, woran zu erkennen ist,


ob der installierte AntiVir-Scanner mit seiner Rechnerumgebung harmoniert
und 


woher man im Falle von Inkonsistenzen Updates beziehen kann.


Hintergrund


Nahezu sämtliche Bestandteile eines UNIX-Systems (das OS selbst, die systemnahen Programme und die überwiegende Mehrzahl aller Applikationen) sind entweder direkt in der Programmiersprache C geschrieben oder basieren auf Komponenten, die in C geschrieben wurden.


Basisroutinen, auf die sich Applikationen bei ihrer Arbeit stützen, finden sich typischerweise in der so genannten libc. Dazu gehören die Arbeit mit Dateien, mit dem Arbeitsspeicher, mit dem Netzwerk, das Prozessmanagement und der Zugang zu allen vom Betriebssystem erbrachten Diensten.


Sinnvollerweise werden diese Routinen nicht von jedem Programm immer wieder neu erfunden und mitgeliefert. Sie sind deshalb an zentraler Stelle im System installiert und stehen allen anderen Programmen ständig zur Verfügung. Seitdem UNIX das Konzept der shared libraries (vergleichbar mit den dlls auf anderen Plattformen) unterstützt, ist es üblich, entsprechende Applikationen als so genannte dynamically linked binaries zu verteilen. Das zugrunde liegende Basissystem liefert die erst zum Zeitpunkt des Programmstarts hinzugelinkte C-Bibliothek mit.


Die unter Linux am häufigsten anzutreffende Implementierung dieser libc ist die glibc → Homepage.
Wie alle beliebten und weit verbreiteten Open-Source-Projekte befindet sich dieser Code in einer permanenten Entwicklungs- und Überarbeitungsphase. Bugs werden beseitigt, Funktionalitäten erweitert, Ergänzungen implementiert. In diesem lebendigen Prozess erfolgt ein permanenter Abgleich mit den allgemeinen Standards, die sich ebenfalls stetig verändern und weiterentwickeln.


Fast zwangsläufig bleibt dadurch nicht aus, dass sich hier und da gewisse Deckungsungleichheiten bilden. Mitunter ergibt sich zwar „an der Oberfläche“ ein homogenes, kongruentes Bild, doch in tieferen Bereichen können Abweichungen dafür sorgen, dass sich die genutzten Applikationen veränderten Bedingungen gegenüber sehen. Die Folge einer veränderten Semantik kann sein, dass beispielsweise ein Interface, welches Daten auf eine bestimmte Art interpretierte, plötzlich anderen Verarbeitungsprozessen unterworfen ist. Ein möglicher anderer Effekt: Interfaces schlüpfen durch Modifizierung ihrer Parameter in eine andere Gestalt und verändern ihre Arbeitsweise, etwa, weil ihre Funktionalität erweitert wurde.


Aus diesen Gründen ist die Bibliothek (ihr aktueller Entwicklungszustand und damit ihr Verhalten) streng versioniert. Allerdings sind nicht alle im Einsatz befindlichen Versionen miteinander „kreuz und quer“ in alle Richtungen kompatibel.


In der Regel wird zwar eine Auf- und Abwärtskompatibilität angestrebt. Erreicht werden kann sie aber (wenn überhaupt) nur über eng benachbarte Versionen. Anders gesagt: Im wahrsten Sinne des Wortes ist die Kompatibilität nicht in der Lage, große Sprünge zu machen.


Was also ist zu tun? Liegen die Quellen des Betriebssystems und der Applikationen vor, bietet sich eine Übersetzung des vollständigen Systems an, um auf diese Weise einen konsistenten Zustand zu erreichen. Werden Applikationen als binaries bezogen, muss beim Download die korrekte Version ausgewählt werden. Bei Updates der Basiskomponenten ist zu beachten, dass es Abhängigkeiten in den darüber liegenden Komponenten geben könnte und auch diese ggf. einem Update unterworfen werden müssen. Wird beispielsweise ein so essentieller Systembestandteil wie die libc ausgetauscht oder auf einen anderen Versionsstand angehoben, kann es durchaus notwendig werden, nicht nur das Basissystem, sondern die komplette Applikationssoftware upzudaten.
 

Ermittlung der Bibliotheks-Version bzw. der von AntiVir unterstützten Versionen


Mag es auch eigenartig klingen: Aus Gründen der Kompatibilität und Interoperabilität ist eine laufende Applikation nicht in der Lage, die Version der installierten libc zu ermitteln und damit zu bestimmen, ob sie in dieser Umgebung prinzipiell laufen kann. Im Design der Bibliothek ist gar nicht erst vorgesehen, die Version zu ermitteln (falls es doch einzelne Implementierungen gibt, die dieses Feature bieten, funktioniert das Verfahren noch lange nicht auf allen anderen Systemen und Plattformen). Gleichzeitig handelt es sich hier um ein typisches Henne-und-Ei-Problem: Wie soll – bei Inkonsistenz der benötigten und der vorhandenen Versionen – eine nicht lauffähige Applikation starten und anschließend ihre eigene Lauffähigkeit testen?


Leider können wir als Software-Hersteller unseren Anwendern den hier beschriebenen Aufwand nicht abnehmen und ihnen die Arbeit so erleichtern, wie wir es gern tun würden. Die oben beschriebene Situation erfordert, dass der Netzwerk-Administrator stets für einen konsistenten Stand der installierten Software sorgt – diese Aufgabe kann ihm niemand abnehmen. Aber wir möchten zumindest einen Leitfaden zur Erkennung und Behebung von Problemen anbieten.


Problembehebung


Die folgenden Hinweise beziehen sich auf Linux und die GNU-C-Bibliothek. Auf anderen Plattformen gelten die oben angesprochenen Aspekte selbstverständlich ebenso, aber bisher gibt es nur unter Linux und zusammen mit der GNU libc zwingend das Gebot, eine der angebotenen Versionen auszuwählen.


Die glibc liegt auf der Festplatte in einem Format vor, welches erlaubt, sie wie ein „normales Programm“ zu benutzen. Dies ist nicht nur während der Entwicklungsphase hilfreich, sondern erlaubt später bei der Auslieferung die Ausgabe essentieller Informationen.


Der Aufruf von


/lib/libc.so.6 | head -1


zeigt die Versionsnummer an (eigentlich ist die Ausgabe deutlich umfangreicher, aber es wird nur die Zeile mit der Versionsnummer ausgefiltert). Sollte dieser Befehl die Ausgabe einer Art „Permission denied“ zur Folge haben, oder geht die Datei aus anderen Gründen nicht als „Programm“ durch, kann ein Start mit folgendem Befehl versucht werden:



/lib/ld-linux.so.2 /lib/libc.so.6 | head -1


Beginnt die Versionsnummer mit 2.0 oder 2.1, sind die mit glibc20 markierten Archive unserer Software einzusetzen. Beginnt die Versionsnummer mit 2.2 oder 2.3, müssen die mit glibc22 markierten Archive eingesetzt werden. Freilich kann die libc auch in der (internen) Version 1 vorliegen und hat dann den Dateinamen libc.so.5. Diese Implementierung ist zwar nicht aktuell und enthält weniger Features, wird aber aufgrund ihres deutlich geringeren Umfangs (die Internationalisierung fehlt) gern in embedded-Systemen eingesetzt bzw. auch dort, wo gespart werden muss oder ein Update nicht zur Debatte steht.


Neben der GNU-Version der libc kommen auch weitere Implementierungen zum Einsatz, die unterschiedliche Ziele verfolgen wie etwa „Schlankheit“ oder „extreme Portabilität“. Da jedoch der Einsatz dieser Software das Resultat bewusster Entscheidungen ist (und nicht „zufällig“ oder durch Installation einer Standard-Distribution erfolgt), gehen wir davon aus, dass die betroffenen Administratoren ihr System sehr genau kennen. Sie beachten die hier diskutierten Punkte ohnehin und wissen genau, welche glibc ihrer eingesetzten Implementierung am besten entspricht. Somit ist ihnen auch geläufig, welches Avira-Software-Archiv sie einsetzen müssen.


Für den seltenen Fall, dass die Datei mit der libc-Implementierung nicht im Verzeichnis lib liegt, sollte der Administrator wissen, wo die Datei zu finden ist. Im Zweifelsfall weiß der loader in einem laufenden System, wo die shared objects zu finden sind. Hier kann man sich bei Zweifeln mit dem Befehl


ldd /bin/ls (oder einem anderen dynamisch gelinkten Programm)


helfen und nach Zeilen mit libc suchen (bzw. nach ldlinux für den weiter oben beschriebenen Fall einer nicht als Programm startenden Bibliothek).


Zusammenfassung

Externe Programme bringen „nur“ die high level Logik der Applikation mit, während sie für die low level Funktionen auf Systembestandteile wie die libc zurückgreifen. Passen diese beiden Komponenten nicht zusammen, kann die Software nicht korrekt funktionieren (während die Palette der Effekte von „scheint zu gehen“ über „geht manchmal, oft aber nicht“ über „geht prinzipiell nicht, tut gar nichts“ bis hin zu „formatiert meine Festplatte, lässt meine Haare ausfallen und macht, dass meine Katze mich nicht mag“ reichen kann).


Anwendungs-Software ist nicht in der Lage, den Test auf Kompatibilität befriedigend durchzuführen, weshalb die Mitarbeit des Administrators unerlässlich ist, der die Konsistenz und Arbeitsfähigkeit des Systems verantwortet. Weil die Linux-Versionen unserer Software in verschiedenen Varianten für verschiedene Umgebungen angeboten werden, ist eine Auswahl nötig, die aufgrund der jeweils installierten C-Bibliothek gefällt wird.


Der vollständige Dateipfad zur installierten C-Bibliothek auf der Festplatte und die Version der eingesetzten Implementation lassen sich mit den folgenden Befehlen erfragen:


$ ldd /bin/ls /bin/bash /usr/bin/vi

 

/bin/ls:

 

librt.so.1 => /lib/librt.so.1 (0x4001e000)

libc.so.6 => /lib/libc.so.6 (0x40030000)

libpthread.so.0 => /lib/libpthread.so.0 (0x40160000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

 

/bin/bash:

 

libdl.so.2 => /lib/libdl.so.2 (0x4001e000)

libc.so.6 => /lib/libc.so.6 (0x40022000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

 

/usr/bin/vi:

 

libncurses.so.5 => /lib/libncurses.so.5 (0x4001e000)

libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40066000)

libdl.so.2 => /lib/libdl.so.2 (0x4006c000)

libperl.so.1 => /usr/lib/libperl.so.1 (0x4006f000)

libcrypt.so.1 => /lib/libcrypt.so.1 (0x4016f000)

libutil.so.1 => /lib/libutil.so.1 (0x4019c000)

libpthread.so.0 => /lib/libpthread.so.0 (0x4019f000)

libm.so.6 => /lib/libm.so.6 (0x401f0000)

libc.so.6 => /lib/libc.so.6 (0x40213000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

 

$ /lib/libc.so.6 | head -1

GNU C Library stable release version 2.3.1, by Roland McGrath et al.

Betroffene Produkte

  • Avira AntiVir MailGate [Linux]
  • Avira AntiVir MailGate [Solaris]
  • Avira MailGate Suite [Linux]
  • Avira WebGate Suite [Linux]
  • Avira WebGate Suite [Solaris]
  • Avira AntiVir Professional, Version 10 [Linux]
  • Avira AntiVir Professional, Version 10 [Solaris]
  • Avira AntiVir Server, Version 10 [Linux]
  • Avira AntiVir Server, Version 10 [Solaris]
  • Erstellt : Mittwoch, 14. März 2007
  • Zuletzt aktualisiert: Montag, 21. März 2011
  • Diesen Artikel bewerten
War das hilfreich?