Lo hice y lo entendí

El blog de Vicente Navarro
08 dic

Monitorizando los mensajes del sistema en la consola y en las X

Si queremos tener una ventana mostrándonos en todo momento los mensajes del sistema, el xconsole es la aplicación que necesitamos:

xconsole

En los escritorios moderno, es fácil configurar la ventana para mantener el xconsole en primer plano.

Aunque la documentación de xconsole diga que accede a /dev/console, en muchas distribuciones (Make xconsole work), para evitar multitud de problemas que ocasiona engancharlo al /dev/console relacionados con la no posibilidad de teclear en las ventanas (sólo con hacer un “xconsole -file /dev/console“, se puede comprobar inmediatamente), normalmente las distribuciones crean una named pipe en /dev/xconsole:

# ll /dev/xconsole
prw-r----- 1 root adm 0 2007-12-08 12:27 /dev/xconsole|

en la que el syslogd escribe, como vemos en el /etc/syslog.conf de Debian:

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
        news.err;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       |/dev/xconsole

Si queremos que algún usuario distinto de root pueda usar el xconsole, habrá que asignarlo al grupo adm (al menos en Debian), pero parece más conveniente simplemente crear un acceso directo usando kdesu o gksu para que nos pregunte el password de root antes de ejecutar el xconsole:

kdesu

Para limpiar los mensajes actuales de la ventana del xconsole, podemos hacer un CONTROL+C sobre ella, como descubrimos en el fichero /etc/X11/app-defaults/XConsole:

*text.baseTranslations:         #override\
        Ctrl<KeyPress>C:        Clear() \n\
        <KeyPress>Clear:        Clear()

Si queremos una especie de equivalente al xconsole en la consola de texto, el syslog.conf estándar de Debian ya nos ofrece una configuración perfectamente válida. Descomentando estas las líneas que envían varias áreas de syslog al /dev/tty8 podremos verlos simplemente pulsando ALT+8 o ALT+CONTROL+8 si estamos en las X:

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
daemon,mail.*;\
        news.=crit;news.=err;news.=notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       /dev/tty8

Tras los cambios al syslog.conf, podemos hacer un /etc/init.d/sysklogd reload para que el cambio tenga efecto.

Hay que tener en cuenta que cualquiera con acceso físico a la máquina (incluso sin usuario válido) podrá ver estos mensajes que pueden llevar información sensible, de forma que hay que usarlo con mucha precaución. Por eso está deshabilitado por defecto.

:wq

Entradas relacionadas

4 Comentarios a “Monitorizando los mensajes del sistema en la consola y en las X”

  • AlBundy dice:

    Hace unos días estuve unas tardes buscando información sobre consolas y mensajes del kernel, y hoy me encuentro en tu blog artículos sobre acceso por modem, /dev/console, netconsole y syslog. Uaooo!!! Muchas gracias.

    Unos matices.
    No entiendo cuando dices que es preferible usar xconsole enganchado al pipe /dev/xconsole “para evitar multitud de problemas que ocasiona engancharlo al /dev/console relacionados con la no posibilidad de teclear en las ventanas”. Por lo que yo entiendo, /dev/console NO está pensado para poder escribir sobre ella mediante teclado.

    Los permisos de /dev/console (rw–w–w-) me hacen dudar. Parece que /dev/console esté ideado para que las aplicaciones puedan escribir logs sobre ella y que dichos mensajes sólo pueda leerlos root. Pero por otro lado, ¿/dev/console no es únicamente para mensajes del kernel?, ¿por qué debería una aplicación escribir sobre él?.

    La utilización de syslog+/dev/xconsole es una manera de puentear los permisos de /dev/console.

    PD: recuerdo en la época de RedHat 5.x cómo en las salas de ordenadores de mi universidad se mostraba la cajita login/password en modo gráfico, con xconsole en la esquina inferior derecha, y al loguearte entrabas con el gestor de ventanas FVWM2, y se mantenía xconsole en pantalla. Tendré que revisar mis viejos CDs y hacer una instalación de prueba, para comprobar como gestionaban los permisos en aquella época.

  • @AlBundy Me alegro de que te haya parecido interesante y/o útil.

    Respecto a:

    Aunque la documentación de xconsole diga que accede a /dev/console, en muchas distribuciones (Make xconsole work), para evitar multitud de problemas que ocasiona engancharlo al /dev/console relacionados con la no posibilidad de teclear en las ventanas…

    puedes probarlo tú mismo fácilmente. Ejecuta “xconsole -file /dev/console” como root dentro de las X y si tu entorno se comporta como el mío, el ratón te seguirá funcionando pero dejarás de poder escribir texto en las ventanas. No me preguntes por qué sucede eso, porque no estoy seguro, pero así es. En el enlace del párrafo anterior también lo cuentan.

    Sobre el /dev/console, en el Documentation/devices.txt de las fuentes del kernel nos aclara para qué sirve:

    The console device, /dev/console, is the device to which system
    messages should be sent, and on which logins should be permitted in
    single-user mode.  Starting with Linux 2.1.71, /dev/console is managed
    by the kernel; for previous versions it should be a symbolic link to
    either /dev/tty0, a specific virtual console such as /dev/tty1, or to
    a serial port primary (tty*, not cu*) device, depending on the
    configuration of the system.

    Por tanto, sirve para mandar los mensajes del sistema y para hacer login en single-user mode.

    Sobre los permisos, parece que en mi Debian no son tan flexibles como los tuyos:

    # ll /dev/console 
    crw------- 1 root root 5, 1 2007-12-05 22:12 /dev/console

    La fecha es reciente porque el fichero de dispositivo es el creado por el udev, pero el fichero de dispositivo estático también tiene los mismos:

    # ll /dev/.static/dev/console 
    crw------- 1 root tty 5, 1 2005-01-10 21:41 /dev/.static/dev/console

    Por tanto, no parece ser un fichero que debiera ser accesible por los usuarios en general...

    Por cierto, yo también he visto esa pantallita del xconsole a menudo. Ahora ya no se estilan esas cosas ;-)

  • AlBundy dice:

    Muchas cosas que comentar, intentaré condensarlas y que no queden muy confusas.

    Para mis pruebas utilizo un kernel 2.4.x con directorio /dev estático sin udev, y sin syslogd (soy un poco rarito, lo reconozco), pero los resultados deberían ser extrapolables a sistemas más modernos.

    Lo que intento es usar /dev/console sin syslogd, pero sospecho que es algo imposible sin abrir pequeños agujeros de seguridad

    Lo que aparece en la carpeta Documentation de las fuentes del kernel es francamente mejorable. Cuando tenga tiempo intentaré enviar algunos parches y que me los acepten.

    Dicen que los “system messages” *deberían* ir a /dev/console; pero no aclaran qué son los “system messages” (NO son todos los mensajes del kernel, tampoco son todos los mensajes de las aplicaciones).

    Sobre los permisos de /dev/console… sería una discusión larga. Durante muchos años han sido crw–w–w-. Otra cosa es que hayan decidido ahora que para más seguridad sea mejor reducirlos a crw——-, y que se pueda hacer un apaño con syslogd.

    También hay que mencionar que el hecho de que los mensajes de las aplicaciones aparezcan en /dev/console o en syslog es cosa del código interno de la aplicación, y no de nuestra configuración. Supongo que será una buena práctica de programación el intentar usar siempre syslogd (que creo recordar que se limita a leer mensajes de /dev/log).

    El init (SysVinit de Miquel van Smoorenburg) que se ha usado tradicionalmente en Linux hace uso de /dev/console y no puede usar syslog (y por cierto, esto me recuerda que te ponga otro comentario en tu otro artículo sobre el usar console=ttyS0,9600n8).

    Y es cierto que ahora no se estila el uso de XDM+xconsole, pero todavía quedan rastros en los ficheros de config de X11. He destripado el paquete XFree86 que venía en una vieja RedHat 6.1, y las cosas NO son muy distintas de los paquetes Xorg actuales.

    El programa xdm era ejecutado por el superusuario desde inittab, y por tanto no tenía problemas de acceso a /dev/console. Cuando el usuario se logueaba con éxito, se ejecutaba un script Xstartup, que a su vez llamaba a un script GiveConsole como este:


    [PS1]% cat /etc/X11/xdm/GiveConsole:
    #!/bin/sh
    # Assign ownership of the console to the invoking user
    # $XConsortium: GiveConsole,v 1.2 93/09/28 14:29:20 gildea Exp $
    #
    # By convention, both xconsole and xterm -C check that the
    # console is owned by the invoking user and is readable before attaching
    # the console output. This way a random user can invoke xterm -C without
    # causing serious grief.
    #
    chown $USER /dev/console
    /usr/X11R6/bin/sessreg -a -w "/var/log/wtmp" -u "/var/run/utmp"\
    -x "/etc/X11/xdm/Xservers" -l $DISPLAY -h "" $USER

    que soluciona el problema de acceso a /dev/console a lo bestia: cambiando su propietario.

    Cuando terminaba la sesión X11, se ejecutaba el script Xreset, que a su vez llamaba a TakeConsole:

    [PS1]% cat /etc/X11/xdm/TakeConsole:
    #!/bin/sh
    # Reassign ownership of the console to root, this should disallow
    # assignment of console output to any random users's xterm
    # $XConsortium: TakeConsole,v 1.2 93/09/28 14:30:29 gildea Exp $
    #
    chmod 622 /dev/console
    chown root /dev/console
    /usr/X11R6/bin/sessreg -d -w "/var/log/wtmp" -u "/var/run/utmp" \
    -x "/etc/X11/xdm/Xservers" -l $DISPLAY -h "" $USER

    que trataba de arreglar el estropicio en usuario y permisos de /dev/console.

    De los comentarios de GiveConsole, podemos ver que si damos permisos peligrosos a /dev/console podemos prescindir incluso de xconsole, ejecutando:

    xterm -C -e bash

    (ó xterm -C simplemente), de manera que los mensajes dirigidos a /dev/console aparezcan en el propio xterm.

    Con permisos peligrosos en /dev/console podemos hacer

    echo "Hello wolrd" >/dev/console

    y aparece “Hello world” en el xconsole, o en el xterm -C.

    Sólo se permite el acceso de un xconsole a /dev/console. Si intentamos acceder con varios a la vez, no nos deja.

    Conclusiones:
    *Los usuarios distintos de root sólo pueden acceder directamente a /dev/console si dicho fichero especial tiene permisos peligrosos.
    *La manera segura de que cualquier usuario visualice mensajes dirigidos a /dev/console es usar syslogd y un FIFO accesorio, tal y como ha explicado Super Coco
    *Ya es hora de que me cree mi propio blog y no envíe comentarios tan largos a los blogs de los demás X-D

  • @AlBundy Muchas gracias por tan detallado e informativo comentario. No te lamentes por enviar comentarios largos porque son muy bienvenidos. Todo lo que sea complementar la información de la entrada se agradece enormemente. Por supuesto, si decides empezar un blog, viendo la calidad de tus reflexiones, no dudes de que aquí tienes al primer subscriptor.

    Respecto al syslogd, como muy bien dices, lee de /dev/log, que no es un fichero de dispositivo sino un socket UNIX:

    # ll /dev/log                                                                            
    srw-rw-rw- 1 root root 0 2007-12-05 22:12 /dev/log=

    Respecto a lo que comentas de qué son los “system messages”, yo pienso que son los del kernel, los que salen en el dmesg. ¿Qué te hace pensar que “NO son todos los mensajes del kernel”?

    Sobre la buena práctica de usar el syslogd, la verdad es que usando el /dev/xconsole te puedes pesonalizar los mensajes que quieres ver y no limitarte a los que el kernel quiera mandar a /dev/console. Si, como dices, no vas a usar el syslogd, te perderás todos los mensajes que las aplicaciones hubieran enviado a dicho demonio, que pueden ser cosas muy importantes, como ya sabes.

    Finalmente, gracias por la muestra de arqueología del software libre al mostrarnos la cómo lo hacía el RH 6.1, que es realmente curioso y, sobre todo, por hablarnos de esa opción -C del xterm que parece muy interesante. Tengo que probarla más detenidamente.

    Gracias por compartir tus experiencias aquí :-)

Tema LHYLE09, creado por Vicente Navarro