Как получить dmidecode информацию без полномочий пользователя root?

Существует допустимая, разумная причина, которую это так путает (существует также раздражающая причина артефакта)...

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

Таким образом, теория состояла бы в том, что Вы создадите что-то в своем корневом каталоге, затем скопируете его в область, которой Вы управляли (Ваша собственная проектная территория или общая область).

Windows PCs является обычно однопользовательскими системами и не имеет этого ограничения, все входит в Программные файлы несмотря ни на что.

Затем существует глупое, раздражающее то, что каждый раз новая версия Unix вышла, создатели чувствовали это необходимый для изменения местоположений, но старые должны были все еще быть там для автоматизированных сценариев. Это дает Вам набор связанных каталогов, служащих той же цели.

init система еще хуже.

16
09.11.2011, 01:45
9 ответов

Я просто проверил свою систему 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 в читаемый миром файл
4
27.01.2020, 19:48

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

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

2
27.01.2020, 19:48
  • 1
    , BIOS также упоминается, поэтому консультируйтесь с журналом ядра или dmesg если это не было заполнено слишком много. Строка в качестве примера: [ 0.000000] DMI: CLEVO CO. B7130 /B7130 , BIOS 6.00 08/27/2010 –  Lekensteyn 09.11.2011, 10:40
  • 2
    cat /sys/devices/virtual/dmi/id/bios_version ... Вуаля'! Но YMMV. Не вся архитектура имеет этот путь. x86_64 Intel должен. –  Mike S 25.10.2017, 22:38

Мы используем DMIDecode для чтения информации из удаленных систем Linux и еще не нашли обходное решение к этому. Я зарегистрировал запрос к dmidecode домашней странице, спрашивающей об этом...

Используя команду dmidecode-t система дает ошибку "/dev/mem: Разрешение отклонило", который является проблемой, поскольку мы не хотим информации о памяти (просто производитель, номер модели и порядковый номер).

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

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

4
27.01.2020, 19:48

lshal содержит большую ту же самую информацию и не требует полномочий пользователя root.

4
27.01.2020, 19:48
  • 1
    я не уверен, почему это было провалено, захватив его, он дал мне точно информацию, в которой я нуждался lshal | grep system.product для имени системы и даже метки лощины с lshal | grep smbios.system.serial –  Mark Booth 07.03.2014, 18:08
  • 2
    @MarkBooth наклонной черты, возможно, потому что HAL удерживается от использования и не поставляется в современных дистрибутивах. –  Ruslan 27.08.2016, 20:14

Наши услуги Linux не работают как корень. В сценарии установки сообщения об/мин (который ДЕЙСТВИТЕЛЬНО работает как корень) мы устанавливаем/etc/sudo.d файл и setcap несколько наших исполняемых файлов (например, для сети широковещательно передает priviledges).

2
27.01.2020, 19:48

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

5
27.01.2020, 19:48
  • 1
    Не уверенный, почему Вы были провалены. Я поместил более подробный ответ на основе Вашего решения для всех видеть. Я думаю, что Ваше решение прекрасно. –  wally 03.09.2014, 18:00

Я не уверен, почему @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 guest)

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


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

Цитирую:

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

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

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

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

4
27.01.2020, 19:48

Некоторая информация, представленная dmidecode , доступна по адресу / sys / devices / virtual / dmi / id .

Другую информацию можно получить, проанализировав / proc / cpuinfo , / proc / meminfo или / sys / system / node / node0 / meminfo .

6
27.01.2020, 19:48
  1. Я могу читать информацию DMI как пользователь под /sys/class/dmi/id/. Не включая серийные номера (для чтения которых требуются привилегии root).

    Я полагаю, что это предполагаемое поведение разработчиков ядра с учетом конфиденциальности.

  2. Regarding dmesg: dmesg - это команда для доступа к кольцевому буферу ядра. Кольцевой буфер подразумевает, что старая информация перезаписывается более новой, когда буфер "переполняется". Также это чтение отладочного вывода модуля ядра, который никогда не предназначался для разбора.

  3. Для доступа к выводу ядра с помощью systemd выполните:

    journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
    
  4. По поводу ответов david-homer и nils: Файл /dev/mem не просто предоставляет информацию о памяти, а отображает всю физическую память в пользовательское пространство. Поэтому через него можно получить доступ к адресам памяти DMI (и делать гораздо более неприятные вещи).

  5. По поводу chgrp и chmod g+s из dmidecode в ответе nils': Полагаю, это не сработает так, как задумано, потому что сохранение gid с помощью chmod g+s не заставит dmidecode использовать свои новые привилегии. dmidecode должен вызвать setegid, чтобы установить свой эффективный идентификатор группы, прежде чем он сможет получить доступ к /dev/mem. Судя по исходному коду, dmidecode этого не делает.

6
27.01.2020, 19:48

Теги

Похожие вопросы