Как получить информацию о 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. Используйте sudo
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. Чтобы получить доступ к выводу ядра с помощью команды systemdrun:

   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: Permission denied", которая является проблемой, поскольку нам не нужна информация о памяти (только производитель, модель и серийный номер).

Я заметил, что команда 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'

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

Я что-то упустил очевидное?

Обновление: Спасибо @Ruslan за указание на очевидное, что я пропустил.

Цитирование:

Да у тебя есть. Сообщения ядра хранятся в кольцевом буфере. Когда напечатано слишком много строк, первые удаляются.

Поэтому, если ваша машина проработала несколько недель, и вы приостановили / возобновили ее хотя бы каждый день, высока вероятность того, что информация, которую вы здесь найдете, больше не будет в буфере.

(У меня такая ситуация с временем безотказной работы 18 дней здесь.) Может быть, лучше изучить /var/log/kern.log

Что-то вроде grep DMI: /var/log/kern.log | tail -n1

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

Версия BIOS более сложная, я не верю, что это возможно для пользователя без полномочий root, но я могу ошибаться. Возможно, что оно (и название системного продукта) где-то раскрыто, может быть, в /sys/или /proc/, но я ничего не могу найти.

Наши сервисы Linux не запускаются с правами root. В сценарии после установки RPM (который запускается как root) мы устанавливаем файл /etc/sudo.d и устанавливаем несколько наших исполняемых файлов (например, для привилегий сетевого вещания).