Jak uzyskać informacje o kodzie dmidecode bez uprawnień roota?

Piszę program, który wyświetla różne informacje o systemie (w systemie CentOS). Na przykład typ i szybkość procesora (od /proc/cpuinfo), czas ostatniego uruchomienia (obliczony na podstawie /proc/uptime), adres IP (z ifconfigwyjścia) oraz lista zainstalowanych drukarek (z lpstatwyjścia).

Obecnie z dmidecodeprogramu pozyskuje się kilka danych :

• Typ platformy ( dmidecode -s system-product-name)
• Wersja systemu BIOS ( dmidecode -s bios-version)
• Ilość pamięci fizycznej ( dmidecode -t17 | grep Size)

Są one dostępne tylko wtedy, gdy mój program jest uruchomiony jako root (ponieważ w przeciwnym razie dmidecodepodproces nie powiedzie się z /dev/mem: Permission deniedbłędem). Czy istnieje alternatywny sposób uzyskania tych informacji, do których normalny użytkownik może uzyskać dostęp?

Właśnie sprawdziłem system CentOS 5 - po:

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

Nadal nie jest możliwe uruchomienie kodu dmidecode - grupa kmem ma tylko prawa do odczytu dla / dev / mem - wydaje się, że w celu uzyskania informacji o BIOSie jest zaangażowany zapis.

Więc kilka innych opcji:

1. Użyj sudo
2. Użyj innych źródeł informacji (np. / Proc / meminfo)
3. Użyj skryptu inicjującego, który zapisuje statyczne wyjście kodu dmidecode do pliku czytelnego dla świata

Niektóre informacje przedstawione przez dmidecodesą dostępne pod adresem /sys/devices/virtual/dmi/id.

Pozostałe informacje można uzyskać analizując /proc/cpuinfo, /proc/meminfoczy /sys/system/node/node0/meminfo.

1. Mogę odczytać informacje DMI jako Użytkownik pod /sys/class/dmi/id/. Bez numerów seryjnych (które wymagają uprawnień roota do odczytu).

   Sądzę, że jest to zamierzone zachowanie programistów jądra świadomych prywatności.

2. Odnośnie dmesg: dmesgto polecenie dostępu do bufora pierścienia jądra. Bufor pierścieniowy oznacza, że ​​starsze informacje są zastępowane nowszymi, gdy bufor jest „przepełniony”. Odczytuje to również wyjście debugowania modułu jądra, które nigdy nie miało być analizowalne.

3. Aby uzyskać dostęp do danych wyjściowych jądra za pomocą polecenia systemdrun:

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

4. Odnośnie odpowiedzi Davida-homera i nilsa : plik /dev/memnie tylko podaje informacje o pamięci, ale mapuje całą pamięć fizyczną do przestrzeni użytkownika. Dlatego można za jego pośrednictwem uzyskać dostęp do adresów pamięci DMI (i robić o wiele bardziej paskudne rzeczy).

5. Odnośnie chgrpi chmod g+sstanowi dmidecodew Nils' odpowiedź: myślę, że to nie będzie działać zgodnie z przeznaczeniem, bo oszczędności z GID chmod g+snie czyni dmidecodewykorzystywać to nowe przywileje. dmidecodemusi zadzwonić, setegidaby ustawić efektywny identyfikator grupy, zanim będzie mógł uzyskać dostęp /dev/mem. Sądząc z kodu źródłowego, dmidecodenie robi tego.

Wypróbuj dmesg. W ten sposób udało mi się uzyskać potrzebne informacje na zwykłym koncie użytkownika.

Używamy kodu DMID do odczytu informacji ze zdalnych systemów Linux i jeszcze nie znaleźliśmy rozwiązania tego problemu. Zalogowałem połączenie na stronie głównej dmidecode, pytając o to ...

Użycie polecenia dmidecode -t system daje błąd „/ dev / mem: Permenie denied”, który jest problemem, ponieważ nie chcemy informacji o pamięci (tylko producent, model i numer seryjny).

Zauważam, że polecenie smbios działające w systemie SunOS działa dobrze dla tych informacji bez konieczności posiadania uprawnień roota.

Na razie zamierzam zastąpić naszą dokumentację stwierdzającą, że „używaj określonego konta z najmniej wymaganym przywilejem” na „poświadczenia użytkownika root”.

lshal zawiera wiele takich samych informacji i nie wymaga uprawnień administratora.

Nie jestem pewien, dlaczego @mtneagle został odrzucony.

Trzy elementy, których chciał PO, to:

Typ platformy ( dmidecode -s system-product-name)
Wersja systemu BIOS ( dmidecode -s bios-version)
Ilość pamięci fizycznej ( dmidecode -t17 | grep Size)

W ten sposób możemy uzyskać każdy z nich:

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'

(A przynajmniej te działają na 4 różnych serwerach sprzętowych, które mam, i czysto nie zwróciły niczego dla BIOSu lub typu serwera dla gościa Xen.)

Czy przegapiłem coś oczywistego?

Aktualizacja: Podziękowania dla @Ruslan za wskazanie oczywistych rzeczy, za którymi tęskniłem.

Cytowanie:

Tak ty masz. Wiadomości jądra są przechowywane w buforze pierścieniowym. Gdy wydrukowano zbyt wiele wierszy, pierwsze są usuwane.

Więc jeśli twoja maszyna działała przez wiele tygodni, a zawieszałeś / wznawiałeś ją co najmniej codziennie, istnieje duże prawdopodobieństwo, że informacje, o których tu prosisz, nie będą już przechowywane w buforze.

(Mam taką sytuację z 18-dniowym czasem bezczynności.) Lepiej się przyjrzeć /var/log/kern.log

Coś jak grep DMI: /var/log/kern.log | tail -n1

Aby uzyskać całkowitą ilość pamięci fizycznej, można analizować /proc/meminfo, free, vmstat, itd. Można też analizować bufor komunikatów jądra, ponieważ mówi o nim w czasie 0.

Wersja systemu BIOS jest trudniejsza, nie sądzę, że jest to możliwe jako użytkownik inny niż root, ale mogę się mylić. Możliwe, że to (i nazwa produktu systemowego) jest gdzieś ujawnione, może w /sys/lub /proc/, ale nic nie mogę znaleźć.

Nasze usługi Linux nie działają jako root. W skrypcie poinstalacyjnym RPM (który MUSI działać jako root) instalujemy plik /etc/sudo.d i ustawiamy kilka plików wykonywalnych (np. W przypadku uprawnień do transmisji sieciowych).