Comment obtenir des informations dmidecode sans privilèges root?

J'écris un programme qui affiche diverses informations système (sur un système CentOS). Par exemple, le type et la vitesse du processeur (à partir de /proc/cpuinfo), la dernière heure de démarrage (calculée à partir de /proc/uptime), l'adresse IP (à partir de la ifconfigsortie) et une liste d'imprimantes installées (à partir de la lpstatsortie).

Actuellement, plusieurs données sont obtenues à partir du dmidecodeprogramme:

• Le type de plateforme ( dmidecode -s system-product-name)
• La version du BIOS ( dmidecode -s bios-version)
• La quantité de mémoire physique ( dmidecode -t17 | grep Size)

Ceux-ci ne sont disponibles que si mon programme est exécuté en tant que root (car sinon le dmidecodesous - processus échoue avec une /dev/mem: Permission deniederreur). Existe-t-il un autre moyen d'obtenir ces informations, auquel un utilisateur normal peut accéder?

Je viens de vérifier mon système CentOS 5 - après:

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

Il n'est toujours pas possible de faire fonctionner dmidecode - le groupe kmem n'a que les droits de lecture pour / dev / mem - il semble qu'il y ait une écriture impliquée pour accéder aux informations du BIOS.

Donc, d'autres options:

1. Utilisez sudo
2. Utiliser d'autres sources d'informations (par exemple / proc / meminfo)
3. Utilisez un script d'initialisation qui écrit la sortie statique de dmidecode dans un fichier lisible par le monde

Certaines des informations présentées par dmidecodesont disponibles sur /sys/devices/virtual/dmi/id.

D'autres informations peuvent être obtenues en analysant /proc/cpuinfo, /proc/meminfoou /sys/system/node/node0/meminfo.

1. Je peux lire les informations DMI en tant qu'utilisateur sous /sys/class/dmi/id/. N'inclut pas les numéros de série (qui nécessitent des privilèges root pour lire).

   Je suppose que c'est le comportement voulu des développeurs de noyau soucieux de la confidentialité.

2. Concernant dmesg: dmesgest une commande pour accéder au tampon d'anneau du noyau. Le tampon en anneau implique que les informations plus anciennes sont remplacées par des nouvelles lorsque le tampon "déborde". C'est également la lecture de la sortie de débogage du module du noyau qui n'a jamais été conçue pour être analysable.

3. Pour accéder à la sortie du noyau avec systemdrun:

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

4. Concernant les réponses de David-Homer et Nils : Le fichier /dev/memne donne pas simplement des informations sur la mémoire, mais mappe toute la mémoire physique dans l'espace utilisateur. Par conséquent, on peut accéder aux adresses mémoire DMI à travers elle (et faire des choses beaucoup plus désagréables).

5. Concernant chgrpet chmod g+sde dmidecodedans la réponse de nils : Je suppose que cela ne fonctionnera pas comme prévu, car l'enregistrement de gid avec chmod g+sne fait pas dmidecodeusage de ses nouveaux privilèges. dmidecodedoit appeler setegidpour définir son identifiant de groupe effectif avant de pouvoir y accéder /dev/mem. À en juger par son code source, dmidecodene fait pas cela.

Essayez le dmesg. J'ai pu obtenir les informations que je voulais de cette façon avec un compte utilisateur normal.

Nous utilisons DMIDecode pour lire les informations des systèmes Linux distants et nous n'avons pas encore trouvé de solution à ce problème. J'ai enregistré un appel sur la page d'accueil de dmidecode à ce sujet ...

L'utilisation de la commande dmidecode -t system donne l'erreur "/ dev / mem: Autorisation refusée" qui est un problème car nous ne voulons pas d'informations sur la mémoire (juste le fabricant, le modèle et le numéro de série).

Je remarque que la commande smbios exécutée sur SunOS fonctionne correctement pour ces informations sans avoir besoin du privilège root.

Pour l'instant, je vais remplacer notre documentation indiquant "utiliser un compte spécifique avec le privilège le moins requis" par "les informations d'identification de l'utilisateur root".

lshal contient beaucoup de ces mêmes informations et ne nécessite pas de privilèges root.

Je ne sais pas pourquoi @mtneagle a été rejeté.

Les trois éléments recherchés par le PO sont:

Le type de plate-forme ( dmidecode -s system-product-name)
La version du BIOS ( dmidecode -s bios-version)
La quantité de mémoire physique ( dmidecode -t17 | grep Size)

Nous pouvons obtenir chacun de ces éléments ainsi:

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'

(Ou du moins ceux qui fonctionnent sur les 4 serveurs matériels différents que j'ai, et n'ont rien renvoyé proprement pour le BIOS ou le type de serveur sur un invité Xen.)

Ai-je raté quelque chose d'évident?

Mise à jour: Merci à @Ruslan d'avoir souligné l'évident qui m'a manqué.

Citant:

Oui tu as. Les messages du noyau sont stockés dans un tampon en anneau. Lorsque trop de lignes ont été imprimées, les premières sont supprimées.

Donc, si votre machine a fonctionné pendant plusieurs semaines et que vous l'avez suspendue / reprise au moins tous les jours, il y a de fortes chances que les informations que vous recherchez ici ne soient plus dans le tampon.

(J'ai une telle situation avec un temps de disponibilité de 18 jours ici.) Il peut être préférable d'examiner /var/log/kern.log

Quelque chose comme grep DMI: /var/log/kern.log | tail -n1

Pour obtenir le montant total de la mémoire physique, vous pouvez analyser /proc/meminfo, free, vmstat, etc. Vous pouvez également analyser le tampon des messages du noyau, car il en parle à 0 heure.

La version du BIOS est plus difficile, je ne pense pas que cela soit possible en tant qu'utilisateur non root, mais je peux me tromper. Il est possible qu'il (et le nom du produit système) soient exposés quelque part, peut-être dans /sys/ou /proc/, mais je ne trouve rien.

Nos services Linux ne fonctionnent pas en tant que root. Dans le script de post-installation RPM (qui s'exécute en tant que root), nous installons un fichier /etc/sudo.d et définissons quelques-uns de nos exécutables (par exemple pour les privilèges de diffusion réseau).