[suse-linux-s] script para averiguar procesos que reiniciar despues de una actualizacion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola:
Una de las peculiaridades de los sistemas de ficheros en linux es que, si
se borra un fichero que está abierto, el fichero se borra en el
directorio, pero en realidad no se borra hasta que el proceso que lo tiene
abierto lo suelte. El inodo queda guardado en el kernel.
Así, cuando el YOU hace una actualización de algún rpm, si el demonio que
se ha actualizado no se reinicia, lo que se sigue ejecutando es la versión
antigua, y no se borra del disco efectivamente hasta el reinicio del
servicio.
Lo curioso es que con el comando "lsof" se pueden encontrar esos inodos
pendientes, porque contiene la palabra "RPMDELETE" o "path inode=" y son
identificables.
He aquí un pequeño script que publicaron en la lista de seguridad (algo
modificado por mi) y que permite localizar esos procesos. Queda adivinar
cual es el servicio correspondiente, pero eso es fácil.
Se supone que funciona al menos en las versiones 9.x de SuSE, en la 10.x
no lo he probado. En la 7.3 también funciona.
#!/bin/bash
#/usr/local/bin/rpm_pending
# Check there are no processes using software that has been updated by rpm.
# Date: Tue, 10 Jan 2006 10:14:59 +0000 (GMT)
# From: Bob Vickers
# Subject: Re: [suse-security] Patch Noifications
# PATH=/bin:/usr/bin
set -o nounset
#if [ $# -eq 1 ]
#then
# lines=$1
#else
# lines=10
#fi
# Run lsof and scan the output for libraries that have been updated. Before
# SuSE 9.1 these will include the string RPMDELETE, but in 9.1 they include
# a semi-colon.
# In 9.2 and 9.3 they include the string 'path inode='
#
# Ejecutar lsof y explorar la salida buscando librerías actualizadas.
# Antes de SuSE 9.1 ésta contendrá la frase RPMDELETE, pero en 9.1
# incluyan un punto y coma.
# En 9.2 y 9.3 incluyen la frase 'path inode='
# Dos versiones: la primera sólo saca las primeras n lineas (como
# parámetro al comando) - reactivar el párrafo de código arriba también
# La otra simplemente lo vuelca todo (mi variación y la que he dejado)
#procs=`lsof | grep -E 'RPMDELETE|;|path inode=' | head -$lines`
procs=`lsof | grep -E 'RPMDELETE|;|path inode=' `
if [ -n "$procs" ]
then
host=`hostname`
cat <
Hola:
Una de las peculiaridades de los sistemas de ficheros en linux es que, si se borra un fichero que está abierto, el fichero se borra en el directorio, pero en realidad no se borra hasta que el proceso que lo tiene abierto lo suelte. El inodo queda guardado en el kernel.
¿Y cómo han hecho esto? ¿Toqueteando filesystem? ¿Kernel?
Así, cuando el YOU hace una actualización de algún rpm, si el demonio que se ha actualizado no se reinicia, lo que se sigue ejecutando es la versión antigua, y no se borra del disco efectivamente hasta el reinicio del servicio.
Lo curioso es que con el comando "lsof" se pueden encontrar esos inodos pendientes, porque contiene la palabra "RPMDELETE" o "path inode=" y son identificables.
He aquí un pequeño script que publicaron en la lista de seguridad (algo modificado por mi) y que permite localizar esos procesos. Queda adivinar cual es el servicio correspondiente, pero eso es fácil.
Se supone que funciona al menos en las versiones 9.x de SuSE, en la 10.x no lo he probado. En la 7.3 también funciona.
#!/bin/bash #/usr/local/bin/rpm_pending # Check there are no processes using software that has been updated by rpm.
# Date: Tue, 10 Jan 2006 10:14:59 +0000 (GMT) # From: Bob Vickers # Subject: Re: [suse-security] Patch Noifications
# PATH=/bin:/usr/bin
set -o nounset
#if [ $# -eq 1 ] #then # lines=$1 #else # lines=10 #fi
# Run lsof and scan the output for libraries that have been updated. Before # SuSE 9.1 these will include the string RPMDELETE, but in 9.1 they include # a semi-colon. # In 9.2 and 9.3 they include the string 'path inode=' # # Ejecutar lsof y explorar la salida buscando librerías actualizadas. # Antes de SuSE 9.1 ésta contendrá la frase RPMDELETE, pero en 9.1 # incluyan un punto y coma. # En 9.2 y 9.3 incluyen la frase 'path inode='
# Dos versiones: la primera sólo saca las primeras n lineas (como # parámetro al comando) - reactivar el párrafo de código arriba también # La otra simplemente lo vuelca todo (mi variación y la que he dejado)
#procs=`lsof | grep -E 'RPMDELETE|;|path inode=' | head -$lines` procs=`lsof | grep -E 'RPMDELETE|;|path inode=' `
if [ -n "$procs" ] then host=`hostname` cat <
La máquina $host tiene ficheros obsoletos todavía en uso por procesos en ejecución. Esto puede constituir un riesgo de seguridad, así que debería reinicializar los daemons que hagan falta.
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
EOF echo "$procs" exit 1 else exit 0 fi
Gracias pues. -- Jordi Espasa Clofent PGP id 0xC5ABA76A #http://pgp.mit.edu/ FSF Associate Member id 4281 #http://www.fsf.org/
Hola :) El Viernes, 2 de Junio de 2006 08:17, Jordi Espasa Clofent escribió:
Hola:
Una de las peculiaridades de los sistemas de ficheros en linux es que, si se borra un fichero que est� abierto, el fichero se borra en el directorio, pero en realidad no se borra hasta que el proceso que lo tiene abierto lo suelte. El inodo queda guardado en el kernel.
�Y c�mo han hecho esto? �Toqueteando filesystem? �Kernel?
Esto es típico de Linux, hasta que no se cierran los file-descriptors, no se borra realmente un fichero. Hay un experimento muy sencillo y consiste en: - crear un fichero de texto - abrirlo con less o vi o emacs o lo que sea - en otra shell borras el fichero - ahora tecleas losf | grep -i "(nombre_del_fichero|comando)" te aparecerá el file descriptor - haces un cat file_descriptor> fichero_nuevo - tienes una copia del fichero :) Esto se puede hacer, por ejemplo con streams de audio y vídeo. También tiene una "utilidad" que es "espiar"/"controlar" (robar información) de alguien que tiene un fichero abierto. Obviamente no es tan sencillo puesto que tendrías que tener permiso para poder hacerle un cat al fd del fichero, por ejemplo, tendrías que ser root. Hablando de seguridad, en el otro hilo se ha hablado de SQL injection y colegas, pero no se ha hecho mención (que yo sepa) a los root shells. Es también interesante tener cuidado con este tipo de vulnerabilidades. HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman -- 50% of all statistics are inaccurate. OpenWengo: rgriman -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Gracias por la explicación/aclaración. Pequeño Padawan (usease: yo mismo) abriendo ojos y desenmarañando orejas.... -- Jordi Espasa Clofent PGP id 0xC5ABA76A #http://pgp.mit.edu/ FSF Associate Member id 4281 #http://www.fsf.org/
Pequeño Padawan (usease: yo mismo) abriendo ojos y desenmarañando orejas....
je je, pues yo... ni te cuento ;-) Por cierto, que hay un tio en suse, que tb usaba el rollito Yoda para explicar cosas tan simples como esas y otras :D (Henne V.?) -- Saludos, miguel -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El Viernes, 2 de Junio de 2006 4:52 AM, Rafa Grimán escribió:
Hola :)
El Viernes, 2 de Junio de 2006 08:17, Jordi Espasa Clofent escribió:
Hola:
Una de las peculiaridades de los sistemas de ficheros en linux es que, si se borra un fichero que est� abierto, el fichero se borra en el directorio, pero en realidad no se borra hasta que el proceso que lo tiene abierto lo suelte. El inodo queda guardado en el kernel.
�Y c�mo han hecho esto? �Toqueteando filesystem? �Kernel?
Esto es típico de Linux, hasta que no se cierran los file-descriptors, no se borra realmente un fichero. Hay un experimento muy sencillo y consiste en: - crear un fichero de texto - abrirlo con less o vi o emacs o lo que sea - en otra shell borras el fichero - ahora tecleas
losf | grep -i "(nombre_del_fichero|comando)"
lsof | grep -i ... ;-) -- ************************ Hugo Sandoval Consultor http://www.softwarelibre.com.ve http://www.virtualnet.com.ve http://juegos.virtualnet.com.ve (Juega Lineage II) ************************ <*******> HACKER Persona que disfruta del reto intelectual de superar o rodear las limitaciones de forma creativa... El resto es simple delincuencia. <*******>
Hola :) El Viernes, 2 de Junio de 2006 12:29, Hugo Sandoval escribió:
El Viernes, 2 de Junio de 2006 4:52 AM, Rafa Grimán escribió:
Hola :)
El Viernes, 2 de Junio de 2006 08:17, Jordi Espasa Clofent escribió:
Hola:
Una de las peculiaridades de los sistemas de ficheros en linux es que, si se borra un fichero que est� abierto, el fichero se borra en el directorio, pero en realidad no se borra hasta que el proceso que lo tiene abierto lo suelte. El inodo queda guardado en el kernel.
�Y c�mo han hecho esto? �Toqueteando filesystem? �Kernel?
Esto es típico de Linux, hasta que no se cierran los file-descriptors, no se borra realmente un fichero. Hay un experimento muy sencillo y consiste en: - crear un fichero de texto - abrirlo con less o vi o emacs o lo que sea - en otra shell borras el fichero - ahora tecleas
losf | grep -i "(nombre_del_fichero|comando)"
lsof | grep -i ... ;-)
Es verdad 0:) corrijo: lsof | grep -iE "(nombre_del_fichero|comando)" Gracias :) Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-02 a las 10:52 +0200, Rafa Grimán escribió:
Esto es típico de Linux, hasta que no se cierran los file-descriptors, no se borra realmente un fichero.
O si se cae el sistema, también quedan borrados. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEgBaXtTMYHG2NR9URAs2OAJ4lwFLjGAdGfl0sE1sPiIlQZmSRogCcDHif 1IcNGSpd6AmUzjj/5/pjIqA= =FYWz -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
El Viernes, 2 de Junio de 2006 08:17, Jordi Espasa Clofent escribió:
Así, cuando el YOU hace una actualización de algún rpm, si el demonio que se ha actualizado no se reinicia, lo que se sigue ejecutando es la versión antigua, y no se borra del disco efectivamente hasta el reinicio del servicio.
* En las actualizaciones se hace automaticamente a voluntad, /etc/sysconfig/services
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-02 a las 14:26 +0200, jose maria escribió:
El Viernes, 2 de Junio de 2006 08:17, Jordi Espasa Clofent escribió:
Así, cuando el YOU hace una actualización de algún rpm, si el demonio que se ha actualizado no se reinicia, lo que se sigue ejecutando es la versión antigua, y no se borra del disco efectivamente hasta el reinicio del servicio.
* En las actualizaciones se hace automaticamente a voluntad, /etc/sysconfig/services
Ya, te refieres a: DISABLE_RESTART_ON_UPDATE="no" Pero no funciona siempre, lo he comprobado. Hay actualizaciones que, desde que he usado ese script, he pillado cosas no reiniciadas. Por ejemplo, si actualizas una librería que usa el apache, pero no lo que es el rpm del apache, el apache no se reinicia automáticamente porque no se ha actualizado; pero si corres el script ves que hay cosas pendientes que te das cuenta piden reiniciar el apache. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEgFMTtTMYHG2NR9URAv5rAJ99jZdHRBND4msZhXeNrgpKiCB/PwCfbe3F dXnNUE+YOCwTgVcDIKfm6cc= =W5GU -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-02 a las 17:02 +0200, escribí:
* En las actualizaciones se hace automaticamente a voluntad, /etc/sysconfig/services
Ya, te refieres a:
DISABLE_RESTART_ON_UPDATE="no"
Pero no funciona siempre, lo he comprobado. Hay actualizaciones que, desde que he usado ese script, he pillado cosas no reiniciadas.
Por ejemplo, si actualizas una librería que usa el apache, pero no lo que es el rpm del apache, el apache no se reinicia automáticamente porque no se ha actualizado; pero si corres el script ves que hay cosas pendientes que te das cuenta piden reiniciar el apache.
Hoy ha pasado eso. El YOU me acaba de actualizar estos parches: whois-52858 postgresql-52896 phpMyAdmin-52901 gdm-52906 Y el script dice que todo esto estos inodos está pendientes: nimrodel:~ # rpm_pending Host nimrodel has obsolete files still in use by running processes. This may constitute a security hazard so you should restart daemons where necessary. COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME snort 4222 snort mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) httpd2-pr 8933 root mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) httpd2-pr 8997 wwwrun mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) httpd2-pr 8998 wwwrun mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) httpd2-pr 28840 wwwrun mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) httpd2-pr 28841 wwwrun mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) httpd2-pr 28842 wwwrun mem REG 22,70 1304453 /usr/lib/libpq.so.3.2 (path inode=1304452) Luego, obviamente, tengo que reiniciar el snort y el apache, que en principio no estaban afectados. El phpMyAdmin toca al apache, o es porque tengo una sesión del phpMyAdmin abierta. Pero, ¿el snort, porqué? Pues porque la librería /usr/lib/libpq.so.3.2 pertenece al postgresql-libs-8.0.8-0.2. Luego veis el interés en verificar a posteriori que todos los servicios afectados se reinician, manualmente, porque de manera automática no sale. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEiYmNtTMYHG2NR9URAhe/AJ4uYT2WViAQe2QEt+PpS9UdNTLQhwCgj5iu BoGpt5kJD3qV9Q86/j1Vs0U= =OC5q -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
participants (7)
-
Carlos E. R. -
Hugo Sandoval -
Jordi Espasa Clofent -
jose maria -
miguel gmail -
Rafa Grimán -
Rafa Grimán