Come ottenere informazioni dmidecode senza i privilegi di root?

Sto scrivendo un programma che visualizza varie informazioni di sistema (su un sistema CentOS). Ad esempio, il tipo e la velocità del processore (da /proc/cpuinfo), l'ultimo tempo di avvio (calcolato da /proc/uptime), l'indirizzo IP ( ifconfigdall'output) e un elenco di stampanti installate ( lpstatdall'output).

Attualmente, dal dmidecodeprogramma vengono ottenuti diversi dati :

• Il tipo di piattaforma ( dmidecode -s system-product-name)
• La versione del BIOS ( dmidecode -s bios-version)
• La quantità di memoria fisica ( dmidecode -t17 | grep Size)

Questi sono disponibili solo se il mio programma viene eseguito come root (perché altrimenti il dmidecodesottoprocesso fallisce con un /dev/mem: Permission deniederrore). Esiste un modo alternativo per ottenere queste informazioni, a cui un normale utente può accedere?

Ho appena controllato il mio sistema CentOS 5 - dopo:

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

Non è ancora possibile far funzionare dmidecode - il gruppo kmem ha solo diritti di lettura per / dev / mem - sembra che ci sia una scrittura coinvolta per accedere alle informazioni del BIOS.

Quindi alcune altre opzioni:

1. Usa sudo
2. Utilizza altre fonti di informazioni (ad es. / Proc / meminfo)
3. Utilizzare uno script init che scriva l'output statico di dmidecode in un file leggibile in tutto il mondo

Alcune delle informazioni presentate da dmidecodesono disponibili all'indirizzo /sys/devices/virtual/dmi/id.

Altre informazioni possono essere ottenute analizzando /proc/cpuinfo, /proc/meminfoo /sys/system/node/node0/meminfo.

1. Posso leggere le informazioni DMI come Utente sotto /sys/class/dmi/id/. Non inclusi i numeri di serie (che richiedono i privilegi di root per la lettura).

   Immagino che questo sia un comportamento previsto dagli sviluppatori del kernel consapevoli della privacy.

2. Riguardo dmesg: dmesgè un comando per accedere al buffer dell'anello del kernel. Il buffer ad anello implica che le informazioni più vecchie vengono sovrascritte da quelle più recenti quando il buffer "trabocca". Anche questo sta leggendo l'output di debug del modulo del kernel che non è mai stato pensato per essere analizzabile.

3. Per accedere all'output del kernel con systemdrun:

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

4. Per quanto riguarda le risposte di David-Homer e Nils : il file /dev/memnon fornisce semplicemente informazioni sulla memoria, ma mappa l'intera memoria fisica nello spazio utente. Pertanto si può accedere agli indirizzi di memoria DMI attraverso di essa (e fare cose molto più brutte).

5. Per quanto riguarda chgrpe chmod g+sdi dmidecodea Nils' risposta: Credo che questo non funzionerà come previsto, in quanto il risparmio gid con chmod g+snon rende dmidecodeutilizzare sia nuovi privilegi. dmidecodedeve chiamare setegidper impostare il suo ID di gruppo effettivo prima che possa accedervi /dev/mem. A giudicare dal suo codice sorgente, dmidecodenon lo fa.

Prova dmesg. Sono stato in grado di ottenere le informazioni che desideravo in questo modo con un normale account utente.

Stiamo usando DMIDecode per leggere informazioni da sistemi Linux remoti e non abbiamo ancora trovato una soluzione a questo. Ho registrato una chiamata nella home page di dmidecode chiedendo di questo ...

L'uso del comando dmidecode -t system dà l'errore "/ dev / mem: Autorizzazione negata" che è un problema poiché non vogliamo informazioni sulla memoria (solo produttore, modello e numero di serie).

Ho notato che il comando smbios in esecuzione su SunOS funziona bene per queste informazioni senza bisogno del privilegio di root.

Per ora ho intenzione di sostituire la nostra documentazione affermando di "utilizzare un account specifico con il privilegio meno richiesto" con "credenziali utente root".

lshal contiene molte delle stesse informazioni e non richiede i privilegi di root.

Non sono sicuro del motivo per cui @mtneagle abbia ricevuto un voto negativo.

I tre elementi desiderati dall'OP sono:

Il tipo di piattaforma ( dmidecode -s system-product-name)
La versione del BIOS ( dmidecode -s bios-version)
La quantità di memoria fisica ( dmidecode -t17 | grep Size)

Possiamo ottenere ognuno di questi così:

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 almeno quelli funzionano sui 4 diversi server hardware che ho e non hanno restituito in modo pulito nulla per BIOS o tipo di server su un guest Xen.)

Ho perso qualcosa di ovvio?

Aggiornamento: Grazie a @Ruslan per aver sottolineato l'ovvio che mi sono perso.

citando:

Sì tu hai. I messaggi del kernel sono memorizzati in un buffer ad anello. Quando sono state stampate troppe righe, le prime vengono eliminate.

Quindi, se la tua macchina ha funzionato per più settimane e l'hai sospesa / ripresa almeno ogni giorno, è molto probabile che le informazioni per cui cerchi qui non saranno più nel buffer.

(Ho una situazione del genere con uptime di 18 giorni qui.) Potrebbe essere meglio esaminare /var/log/kern.log

Qualcosa di simile a grep DMI: /var/log/kern.log | tail -n1

Per ottenere la quantità totale di memoria fisica, si può analizzare /proc/meminfo, free,vmstat , ecc Si può anche analizzare il buffer dei messaggi del kernel, dato che ne parla a 0 tempo.

La versione del BIOS è più difficile, non credo che ciò sia possibile come utente non root, ma potrei sbagliarmi. È possibile che esso (e il nome del prodotto di sistema) siano esposti da qualche parte, forse in /sys/o /proc/, ma non riesco a trovare nulla.

I nostri servizi Linux non funzionano come root. Nello script post installazione RPM (che DOES viene eseguito come root) installiamo un file /etc/sudo.d e impostiamo alcuni dei nostri eseguibili (ad es. Per i privilegi di trasmissione in rete).