¿Cómo obtener información de dmidecode sin privilegios de root?

Estoy escribiendo un programa que muestra diversa información del sistema (en un sistema CentOS). Por ejemplo, el tipo de procesador y la velocidad (desde /proc/cpuinfo), el último tiempo de inicio (calculado desde /proc/uptime), la dirección IP (desde la ifconfigsalida) y una lista de impresoras instaladas (desde la lpstatsalida).

Actualmente, se obtienen varios datos del dmidecodeprograma:

• El tipo de plataforma ( dmidecode -s system-product-name)
• La versión del BIOS ( dmidecode -s bios-version)
• La cantidad de memoria física ( dmidecode -t17 | grep Size)

Estos solo están disponibles si mi programa se ejecuta como root (porque de lo contrario el dmidecodesubproceso falla con un /dev/mem: Permission deniederror). ¿Hay alguna forma alternativa de obtener esta información, a la que pueda acceder un usuario normal?

Acabo de comprobar mi sistema CentOS 5, después de:

chgrp kmem /usr/sbin/dmidecode
chmod g+s /usr/sbin/dmidecode

Todavía no es posible hacer que dmidecode funcione (el grupo kmem solo tiene derechos de lectura para / dev / mem), parece que hay una escritura involucrada para acceder a la información del BIOS.

Entonces algunas otras opciones:

1. Usa sudo
2. Utilice otras fuentes de información (por ejemplo, / proc / meminfo)
3. Use un script de inicio que escriba la salida estática de dmidecode en un archivo legible

Parte de la información presentada por dmidecodeestá disponible en /sys/devices/virtual/dmi/id.

Se puede obtener otra información analizando /proc/cpuinfo, /proc/meminfoo /sys/system/node/node0/meminfo.

1. Puedo leer la información DMI como usuario bajo /sys/class/dmi/id/. No incluye números de serie (que requieren privilegios de root para leer).

   Supongo que este es el comportamiento previsto por los desarrolladores de kernel conscientes de la privacidad.

2. En cuanto a dmesg: dmesges un comando para acceder al búfer de anillo del núcleo. El búfer en anillo implica que los datos nuevos sobrescriben la información anterior cuando el búfer se "desborda". Además, esto es leer la salida de depuración del módulo del kernel que nunca fue pensada para ser analizable.

3. Para acceder a la salida del kernel con systemdrun:

   journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
   

4. Con respecto a las respuestas de david-homer y nils : el archivo /dev/memno solo proporciona información de memoria, sino que asigna toda la memoria física al espacio del usuario. Por lo tanto, se puede acceder a las direcciones de memoria DMI a través de él (y hacer cosas mucho más desagradables).

5. En cuanto chgrpy chmod g+sde dmidecodeen Nils respuesta: Creo que esto no funcionará como se pretende, porque el ahorro de GID con chmod g+sno haga dmidecodeuso de sus nuevas privilegios. dmidecodetiene que llamar setegidpara configurar su identificación de grupo efectiva antes de que pueda acceder /dev/mem. A juzgar por su código fuente, dmidecodeno hace eso.

Prueba dmesg. Pude obtener la información que quería de esta manera con una cuenta de usuario normal.

Estamos utilizando DMIDecode para leer información de sistemas remotos de Linux y todavía no hemos encontrado una solución. He registrado una llamada en la página de inicio de dmidecode preguntando sobre esto ...

El uso del comando dmidecode -t system da el error "/ dev / mem: Permiso denegado", que es un problema ya que no queremos información de memoria (solo fabricante, modelo y número de serie).

Noté que el comando smbios que se ejecuta en SunOS funciona bien para esta información sin necesidad de privilegios de root.

Por ahora voy a reemplazar nuestra documentación que dice "usar una cuenta específica con el privilegio menos requerido" con "credenciales de usuario root".

lshal contiene mucha de esa misma información y no requiere privilegios de root.

No estoy seguro de por qué @mtneagle fue rechazado.

Los tres elementos que el OP quería son:

El tipo de plataforma ( dmidecode -s system-product-name)
La versión del BIOS ( dmidecode -s bios-version)
La cantidad de memoria física ( dmidecode -t17 | grep Size)

Podemos obtener cada uno de estos de esta manera:

dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "1"
dmesg | grep "DMI:" | cut -c "6-" | cut -d "," -f "2"
dmesg | grep "Memory:" | cut -d '/' -f '2-' | cut -d ' ' -f '1'

(O al menos esos funcionan en los 4 servidores de hardware diferentes que tengo, y no devolvieron nada para BIOS o tipo de servidor en un invitado Xen).

¿Me he perdido algo obvio?

Actualización: Gracias a @Ruslan por señalar lo obvio que me perdí.

Citando:

Si tu tienes. Los mensajes del kernel se almacenan en un buffer de anillo. Cuando se han impreso demasiadas líneas, se eliminan las primeras.

Entonces, si su máquina ha funcionado durante varias semanas y la suspendió / reanudó al menos todos los días, es muy probable que la información que obtiene aquí ya no esté en el búfer.

(Tengo una situación de este tipo con un tiempo de actividad de 18 días aquí). Puede ser mejor investigar /var/log/kern.log

Algo como grep DMI: /var/log/kern.log | tail -n1

Para obtener la cantidad total de memoria física, puede analizar /proc/meminfo, free, vmstat, etc. Se puede también analizar el búfer de mensajes del núcleo, ya que habla de ello en el tiempo 0.

La versión del BIOS es más difícil, no creo que esto sea posible como usuario no root, pero puedo estar equivocado. Es posible que (y el nombre del producto del sistema) estén expuestos en algún lugar, tal vez en /sys/o /proc/, pero no puedo encontrar nada.

Nuestros servicios de Linux no se ejecutan como root. En la secuencia de comandos posterior a la instalación de RPM (que se ejecuta como root), instalamos un archivo /etc/sudo.d y configuramos algunos de nuestros ejecutables (por ejemplo, para privilegios de transmisión de red).