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

16

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?

usuario1024
fuente

Respuestas:

4

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
Nils
fuente
6

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.

OluaJho
fuente
1
+1 para /sys/devices/virtual/dmi/id. Mucha información específica de la plataforma está disponible allí. Para ver un script útil, consulte unix.stackexchange.com/questions/75750/… . Para información del sistema, su otra oración también es buena. Hay muchas utilidades como freeo incluso htopque pueden obtener lo que desea.
Mike S
6
  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.

Thomas
fuente
1
Adición a 3 .: para acceder a la salida del kernel en sistemas sin systemdsolo leer /var/log/kern.log. Si no existe dicho archivo mientras el sistema todavía lo está utilizando syslogd, intente buscar kern.*entradas /etc/syslog.confpara averiguar su ubicación.
Ruslan
5

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

mtneagle
fuente
No estoy seguro de por qué te rechazaron. He colocado una respuesta más detallada basada en su solución para que todos la vean. Creo que tu solución está bien.
wally
4

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

David Homer
fuente
4

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

Calvin Locklear
fuente
No estoy seguro de por qué se rechazó esto, al considerarlo me dio exactamente la información que necesitaba lshal | grep system.productpara el nombre del sistema, e incluso la etiqueta de servicio de Dell conlshal | grep smbios.system.serial
Mark Booth
2
@MarkBooth quizás porque HAL está en desuso y no se envía en distribuciones modernas.
Ruslan
lshalfinalmente desapareció por completo en RHEL7 y ahora lo estoy usando sudo cat /sys/devices/virtual/dmi/id/chassis_serialpara obtener la etiqueta de servicio de Dell, pero esto solo funciona porque tengo acceso a cattravés de sudoers.
Mark Booth
4

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

wally
fuente
3
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. Por lo tanto, 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 está grepaquí 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 así como grep DMI: /var/log/kern.log | tail -n1.
Ruslan
Gracias, espero que no te importe, he incluido tu comentario en mi respuesta (con crédito).
wally
2

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.

Chris Down
fuente
2
También se menciona el BIOS, así que consulte el registro del kernel o dmesgsi no se llenó demasiado. Línea de ejemplo:[ 0.000000] DMI: CLEVO CO. B7130 /B7130 , BIOS 6.00 08/27/2010
Lekensteyn
cat /sys/devices/virtual/dmi/id/bios_version... Voila '! Pero YMMV. No todas las arquitecturas tienen este camino. x86_64 Intel debería.
Mike S
2

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

Kezenator
fuente