Informaciones para los usuarios de la Unix glibc

La C-Library (biblioteca c) forma parte de los componentes más importantes del sistema Unix, puesto que es responsable de combinar el proceso de aplicación con el servidor.

En los siguiente le daremos una serie de informaciones básicas con el fin de que pueda reconocer

  • si el escáner de AntiVir que ha instalado harmoniza con su entorno
  • de dónde puede obtener actualizaciones en caso de que aparecieran inconsistencias.

Causas

Prácticamente todos los componentes de un sistema Unix (el OS mismo, los programas que forman parte del sistema y la mayoría de las aplicaciones) están escritos directamente en el lenguaje de programación C o bien yacen sobre componentes escritas en C.

Las rutinas de base, que siven de apoyo a las aplicaciones, se encuentran en la así llamada libc. Aquí incluímos los procesos realizados con los ficheros, la memoria principal, la red, el manejo del proceso y el acceso con todos los servicios puestos a disposición por parte del sistema operativo.

Es lógico que los programas no se inventen estas rutinas de forma nueva cada vez. Éstas están instaladas en el sistema para que todos los demás programas puedan accederlas siempre y cuando lo necesiten. Desde que Unix apoya el concepto de las shared libraries (comparable con las DLLs en otras plataformas), es común distribuír las aplicaciones necesarias en forma de dynamically linked binaries. El sistema básico pone a disposición la biblioteca C que se enlaza a la hora de iniciar el programa.

La implementación más común de la libc en Linux es la glibc. Su sitio Web es: glibc. Al igual que todos los proyectos de código abierto, el código se encuentra en una permanente fase de desarrollo y de reelaboración. Los bugs son eliminados, el número de funcionalidades va en contínuo aumento y de cada vez hay más complementos. En este proceso vivo, los estándards generales se van ajustando contínuamente y éstos a la vez también se encuentran en un proceso de cambio y desarrollo.

La consecuencia de este proceso es que haya incongruencias. La imágen a primera vista da la impresión de ser homogénea y congruente. Sin embargo, puede haber discordancias en las partes más escondidas y éstas pueden causar cambios. La consecuencia de una semántica cambiada puede ser un interfaz que interpreta datos de una forma determinada y que de pronto está obligada a realizar una serie de procesos distintos a los normales. Otro posible efecto es que el interfaz se altere a causa de haber modificado su parámetro y la consecuencia es que altere su funcionamiento.

Por las razones mencionadas, la biblioteca (su estado de desarrollo actual y con ello el comportamiento) están rigidamente unidas a la versión. Sin embergo, no todas las versiones son compatibles la una con la otra.

Por regla general se procura conseguir que las versiones mayores sean compatibles con las menores. Sin embargo, en la mayoría de los casos, esto sólo se consigue con las versiones que no están muy separadas la una de la otra. Dicho de otra manera: la compatibilidades no consigue dar grandes saltos.

Qué solución hay entonces? Si existen las fuentes del sistema operativo y las aplicaciones, se puede traducir el sistema entero con el fin de conseguir un estado consistente. Si las aplicaciones se consiguen en forma de binarios, es importante escoger la versión correcta a la hora de realizar la descarga. Al actualizar los compenentes base se tiene que tener en cuenta que puede haber dependencias entre los componentes que se encuentran por encima y que éstos también se tienen que actualizar. Si por ejemplo se intercambia un componente de sistema tan esencial como la libc o si se sube a otro nivel de versión, puede ser necesario actualizar el software de aplicación en sí aparte de actualizar el sistema base.

Averiguación de la versión de la biblioteca o de las versiones que apoya AntiVir

Puede sonar extraño, pero una aplicación activa no puede averiguar la versión de la libc instalada por motivos de compatibilidad e intercompatibilidad y determinar si funciona en tal entorno. En el diseño de la biblioteca ni tan siquiera se prevé determinar la versión (en caso de que existiera una implementación individual que ofrezca esta función, esto no quiere decir que el proceso funcione en todos los demás sistemas y plataformas). Por otra parte, no es posible conseguir arrancar una versión que no funciona con el fin de probar el funcionamiento si las versiones requeridas y existentes son inconsistentes.

Siendo productores de software desgraciadamente no podemos solucionar este problema que tienen algunos de nuestros usuarios. La situación descrita arriba exige que el administrador del software siempre instalale un software consistente. Sin embargo, lo que sí podemos hacer es ponerles a disposición un breve manual para que pueda reconocer y eliminar posibles problemas.

Solución

Las siguientes indicaciones han sido elaboradas para Linux y la biblioteca GNU-C. Los aspectos mencionados arriba naturalmente también se pueden aplicar para otras plataformas, pero actualmente sólo en Linux y con la GNU libc es obligatorio escoger una de las versiones ofrecidas.

La glibc está en el disco duro en un formato que permite usarla como un programa “normal”. Tal hecho, no únicamente ayuda para la etapa de desarollo, sino que también permite poner a disposición informaciones esenciales a la hora de la extradición.

La elección de

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

muestra el número de la versión (en verdad la información es mucho más extensa, pero únicamente aparece la línea con el número de la versión). En caso de que este comando tenga por consecuencia una especie de “Permission denied” o si el fichero por otras razones no aparece como un “programa”, se puede solucionar con el comando siguiente:

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

Si el número de la versión comienza con 2.0 o 2.1, se tienen que usar los archivos marcados con glibc20 de nuestro software. Si el número de la versión comienza con 2.2 o 2.3, se tienen que usar los archivos marcados con glibc22. La libc también puede aparecer en la versión 1 (interna) con el nombre del fichero libc.so.5. Esta implementación no es la actual y contiene menos funciones (falta la internacionalización), pero al ser menos extensa se puede usar en sistemas embebidos y siempre y cuando se tenga que ahorrar o se pueda realizar una actualización.

Aparte de la versión GNU de la libc hay otras implementaciones que tienen diversas razones como pueden ser “el tamaño reducido” o la “portabilidad extrema”. Pero como el uso de este software es el resultado de decisiones tomadas de forma consciente (y no de forma “casual“ o por haber instalado una distribución estándar), asumimos que los administradores afectados conocen su sistema exactamente. Tienen en cuenta los temas aquí descritos y saben muy bien cuál glibc corresponde mejor con su implementación. Por consiguiente también saben el archivo de software de Avira que deben utilizar.

En caso de que el fichero de la implementación libc no aparezca en el directorio lib, el administrador debe saber dónde se encuentra el fichero. En caso de duda un loader en un sistema activo, sabe donde se encuentran los shared objects. En caso de duda, puede ayudar el comando

ldd /bin/ls (o otro programa enlazado de forma dinámica)

para buscar líneas con libc (o ldlinux para el caso descrito más arriba de una biblioteca que no arranca en forma de un programa).

Conclusión

Los programas externos “sólo” tienen una lógica de muy alto nivel en su aplicación, mientras que recurren a funciones de nivel muy bajo como pueden ser la libc. Si estos dos componentes no compaginan, el software tampoco funciona de forma correcta (el conjunto de efectos va de “parece funcionar” a “funciona de vez en cuando, pero no siempre” o “no funciona en la mayoría de los casos”,...).

El software de aplicación desgraciadamente no consigue una compatibilidad buena, lo cual requiere el trabajo de un administrador responsable de la consistencia y del funcionamiento del sistema. Puesto que ofrecemos nuestras versiones de Linux con variantes diferentes, es muy importante escoger una de entre ellas compatible con la biblioteca C.

Puede determinar la ruta del fichero completa que lleve a la biblioteca C instalada en el disco duro y la versión de la implementación usada con los comandos siguientes.

$ 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.

Productos afectados

  • Avira AntiVir MailGate [Linux]
  • Avira AntiVir MailGate [Solaris]
  • Avira MailGate Suite [Linux]
  • Avira WebGate Suite [Linux]
  • Avira WebGate Suite [Solaris]
  • Avira AntiVir Professional [Linux]
  • Avira AntiVir Professional [Solaris]
  • Avira AntiVir Server [Linux]
  • Avira AntiVir Server [Solaris]
  • Creado : miércoles 14 de marzo de 2007
  • Última actualización: lunes 21 de marzo de 2011
  • Evaluar artículo
¿Le ha sido útil?