Wie bekomme ich dmidecode-Informationen ohne root-Rechte?

Ich schreibe ein Programm, das verschiedene Systeminformationen anzeigt (auf einem CentOS-System). Beispiel: Prozessortyp und -geschwindigkeit (von /proc/cpuinfo), letzte Startzeit (berechnet von /proc/uptime), IP-Adresse (von der ifconfigAusgabe) und Liste der installierten Drucker (von der lpstatAusgabe).

Derzeit werden mehrere Daten aus dem dmidecodeProgramm abgerufen :

• Der Plattformtyp ( dmidecode -s system-product-name)
• Die BIOS - Version ( dmidecode -s bios-version)
• Die Größe des physischen Speichers ( dmidecode -t17 | grep Size)

Diese sind nur verfügbar, wenn mein Programm als root ausgeführt wird (da sonst der dmidecodeUnterprozess mit einem /dev/mem: Permission deniedFehler fehlschlägt ). Gibt es eine alternative Möglichkeit, diese Informationen zu erhalten, auf die ein normaler Benutzer zugreifen kann?

Ich habe gerade mein CentOS 5-System überprüft - nach:

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

Es ist immer noch nicht möglich, dmidecode zum Laufen zu bringen - die Gruppe kmem hat nur Leserechte für / dev / mem - anscheinend ist ein Schreibvorgang erforderlich, um an die BIOS-Informationen zu gelangen.

Also noch ein paar andere Möglichkeiten:

1. Benutze sudo
2. Verwenden Sie andere Informationsquellen (zB / proc / meminfo)
3. Verwenden Sie ein Init-Skript, das die statische Ausgabe von dmidecode in eine weltweit lesbare Datei schreibt

Einige der Informationen , präsentiert von dmidecodefinden Sie unter /sys/devices/virtual/dmi/id.

Weitere Informationen können durch die Analyse erhalten werden /proc/cpuinfo, /proc/meminfooder /sys/system/node/node0/meminfo.

1. Ich kann DMI-Informationen als Benutzer unter lesen /sys/class/dmi/id/. Ohne Seriennummern (die zum Lesen Root-Rechte erfordern).

   Ich denke, dies ist beabsichtigtes Verhalten von Privatsphäre bewusst Kernel-Entwickler.

2. In Bezug auf dmesg: dmesgist ein Befehl für den Kernel - Ringpuffer zugreift. Ringpuffer impliziert, dass ältere Informationen durch neuere überschrieben werden, wenn der Puffer "überläuft". Dies ist auch das Lesen der Kernelmodul-Debug-Ausgabe, die niemals als analysierbar gedacht war.

3. Um den Zugriff Kernel - Ausgang mit systemdLauf:

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

4. Zu den Antworten von david-homer und nils : Die Datei /dev/memgibt nicht nur Speicherinformationen an, sondern ordnet den gesamten physischen Speicher dem Benutzerbereich zu. Daher kann man über sie auf DMI-Speicheradressen zugreifen (und noch viel schlimmere Dinge tun).

5. In Bezug auf chgrpund auf die Antwort chmod g+svon dmidecodein nils : Ich denke, das funktioniert nicht wie vorgesehen, da das Speichern von gid with seine neuen Berechtigungen chmod g+snicht dmidecodenutzt. dmidecodehat nennen setegides die effektive Gruppen - ID zu setzen , bevor sie zugreifen können /dev/mem. Dem Quellcode nach zu urteilen, dmidecodetut das nicht.

Versuchen Sie es mit dmesg. Mit einem normalen Benutzerkonto konnte ich die gewünschten Informationen abrufen.

Wir verwenden DMIDecode, um Informationen von entfernten Linux-Systemen zu lesen, und haben noch keine Lösung dafür gefunden. Ich habe einen Anruf auf der dmidecode-Homepage angemeldet, der mich danach fragt ...

Bei Verwendung des Befehls dmidecode -t wird der Fehler "/ dev / mem: Berechtigung verweigert" ausgegeben, was ein Problem darstellt, da keine Speicherinformationen (nur Hersteller, Modell und Seriennummer) benötigt werden.

Ich stelle fest, dass der unter SunOS ausgeführte Befehl smbios für diese Informationen problemlos funktioniert, ohne dass Root-Berechtigungen erforderlich sind.

Im Moment ersetze ich unsere Dokumentation, die besagt, dass Sie "ein bestimmtes Konto mit den am wenigsten erforderlichen Berechtigungen verwenden", durch "root-Benutzeranmeldeinformationen".

lshal enthält viele der gleichen Informationen und erfordert keine root-Rechte.

Ich bin nicht sicher, warum @mtneagle runtergestimmt wurde.

Die drei Gegenstände, die das OP haben wollte, sind:

Der Plattformtyp ( dmidecode -s system-product-name)
Die BIOS-Version ( dmidecode -s bios-version)
Die Größe des physischen Speichers ( dmidecode -t17 | grep Size)

Wir können jedes von diesen so bekommen:

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'

(Oder zumindest die, die auf den 4 verschiedenen Hardware-Servern funktionieren, die ich besitze, und auf einem Xen-Gast sauber nichts für BIOS oder Servertyp zurückgegeben haben.)

Habe ich etwas Offensichtliches verpasst?

Update: Danke an @Ruslan für den Hinweis auf die offensichtlichen Fehler, die ich verpasst habe.

Zitat:

Ja, du hast. Kernel-Nachrichten werden in einem Ringpuffer gespeichert. Wenn zu viele Zeilen gedruckt wurden, werden die ersten gelöscht.

Wenn Ihre Maschine mehrere Wochen gearbeitet hat und Sie sie mindestens jeden Tag angehalten / fortgesetzt haben, ist die Wahrscheinlichkeit hoch, dass die Informationen, nach denen Sie hier suchen, nicht mehr im Puffer sind.

(Ich habe eine solche Situation mit einer Betriebszeit von 18 Tagen.) Vielleicht ist es besser, sie zu untersuchen /var/log/kern.log

Etwas wie grep DMI: /var/log/kern.log | tail -n1

Um die Gesamtmenge des physischen Speichers zu erhalten, können Sie analysieren /proc/meminfo, free, vmstatusw. Sie können auch die Kernel - Nachrichtenpuffer analysieren, da es darüber zum Zeitpunkt 0 spricht.

Die BIOS-Version ist schwieriger, ich glaube nicht, dass dies als Nicht-Root-Benutzer möglich ist, aber ich kann mich irren. Es ist möglich, dass es (und der Name des Systemprodukts) irgendwo angezeigt wird, vielleicht in /sys/oder /proc/, aber ich kann nichts finden.

Unsere Linux-Dienste werden nicht als Root ausgeführt. In dem RPM-Post-Installationsskript (das als root ausgeführt wird) installieren wir eine /etc/sudo.d -Datei und setzen einige unserer ausführbaren Dateien auf setcap (z. B. für Netzwerk-Broadcast-Berechtigungen).