Як отримати інформацію про dmidecode без привілеїв root?

Я пишу програму, яка відображає різну системну інформацію (у системі CentOS). Наприклад, тип та швидкість процесора (від /proc/cpuinfo), час останнього завантаження (обчислюється з /proc/uptime), IP-адреса (з ifconfigвиходу) та список встановлених принтерів (з lpstatвиводу).

В даний час з dmidecodeпрограми отримується кілька даних :

• Тип платформи ( dmidecode -s system-product-name)
• Версія BIOS ( dmidecode -s bios-version)
• Об'єм фізичної пам'яті ( dmidecode -t17 | grep Size)

Вони доступні лише в тому випадку, якщо моя програма запускається як root (тому що в іншому випадку dmidecodeпідпроцес закінчується /dev/mem: Permission deniedпомилкою). Чи є альтернативний спосіб отримати цю інформацію, щоб звичайний користувач міг отримати доступ?

Я щойно перевірив свою систему CentOS 5 - після:

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

Досі неможливо отримати dmidecode працюючий - kmem групи має лише права читання для / dev / mem - схоже, що для запису інформації про BIOS потрібне записування.

Отож деякі інші варіанти:

1. Використовуйте судо
2. Використовуйте інші джерела інформації (наприклад, / proc / meminfo)
3. Використовуйте init-скрипт, який записує статичний вихід dmidecode у файл, який читається у всьому світі

Деяка інформація, представлена ​​компанією dmidecode, доступна за адресою /sys/devices/virtual/dmi/id.

Іншу інформацію можна отримати, проаналізувавши /proc/cpuinfo, /proc/meminfoабо /sys/system/node/node0/meminfo.

1. Я можу прочитати інформацію DMI як користувач під /sys/class/dmi/id/. Не включаючи серійні номери (для читання яких потрібні кореневі права).

   Я думаю, що це призначена поведінка розробників ядер, відомих конфіденційності.

2. Щодо dmesg: dmesgце команда для доступу до буфера кільця ядра. Буфер кільця означає, що старі відомості перезаписуються новими, коли буфер "переповнюється". Крім того, це зчитування налагодження модуля ядра, який ніколи не був призначений для аналізу.

3. Щоб отримати доступ до виводу ядра з systemdзапуском:

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

4. Щодо відповідей давид-хомера та нуля : файл /dev/memне просто дає інформацію про пам'ять, але відображає всю фізичну пам'ять у просторі користувачів. Тому через нього можна отримати доступ до адрес пам'яті DMI (і зробити набагато більше неприємних речей).

5. Що стосується chgrpі chmod g+sз dmidecodeв NILS ' відповідь: Я думаю , це не буде працювати , як задумано, бо збереження GID з chmod g+sробить dmidecodeвикористовувати його нові привілеї. dmidecodeповинен зателефонувати, setegidщоб встановити його ефективний ідентифікатор групи, перш ніж він отримає доступ /dev/mem. Судячи з його вихідного коду, dmidecodeце не робити.

Спробуйте dmesg. Мені вдалося отримати інформацію, яку я хотів таким чином, за допомогою звичайного облікового запису користувача.

Ми використовуємо DMIDecode для зчитування інформації з віддалених систем Linux і поки не знайшли вирішення цього питання. Я зареєстрував дзвінок на домашній сторінці dmidecode і запитав про це ...

За допомогою команди dmidecode -t система видає помилку "/ dev / mem: дозвіл відхилено", що є проблемою, оскільки ми не хочемо інформації про пам'ять (лише виробник, модель та серійний номер).

Я помічаю, що команда smbios, що працює на SunOS, працює чудово для цієї інформації, не потребуючи привілеїв root.

Поки що я збираюся замінити нашу документацію, яка заявляє, що "використовувати певний обліковий запис з найменш необхідною привілеєм" на "облікові дані користувача root".

lshal містить багато тієї самої інформації і не вимагає привілеїв root.

Я не впевнений, чому @mtneagle проголосував.

Три пункти, які хотіли ОП:

Тип платформи ( dmidecode -s system-product-name)
Версія BIOS ( dmidecode -s bios-version)
Обсяг фізичної пам'яті ( dmidecode -t17 | grep Size)

Ми можемо отримати кожне з них таким чином:

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'

(Або принаймні ті, що працюють на чотирьох різних апаратних серверах, які я маю, і чисто не повернули нічого для BIOS або типу сервера для гостя Xen.)

Я пропустив щось очевидне?

Оновлення: Дякую @Ruslan за вказівку очевидного, що я пропустив.

Цитування:

Так, у вас є. Повідомлення ядра зберігаються в кільцевому буфері. Коли надруковано занадто багато рядків, перші видаляються.

Отже, якщо ваша машина працювала кілька тижнів, і ви призупинили / відновили її принаймні щодня, великі шанси на те, що інформація, яку ви збираєте тут, більше не буде в буфері.

(У мене така ситуація, коли тут працює 18 днів.) Можливо, краще вивчити /var/log/kern.log

Щось на зразок grep DMI: /var/log/kern.log | tail -n1

Для того, щоб отримати загальний обсяг фізичної пам'яті, ви можете розібрати /proc/meminfo, free, vmstatі т.д. Ви можете також розібрати буфер повідомлень ядра, так як він говорить про це в 0 раз.

Версія BIOS є більш складною, я не вважаю, що це можливо як некористувацький користувач, але я можу помилятися. Цілком можливо, що він (і назва продукту системи) десь виставлений, може бути, /sys/або /proc/, але я нічого не можу знайти.

Наші служби Linux не працюють як root. У сценарії RPM post install (який НЕ запускається як root) ми встановлюємо файл /etc/sudo.d і встановлюємо кілька наших виконуваних файлів (наприклад, для привілей мережевих трансляцій).