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í

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

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

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.