Существует допустимая, разумная причина, которую это так путает (существует также раздражающая причина артефакта)...
Unix имеет историю того, чтобы быть многопользовательским, и у большинства пользователей не было доступа для установки приложений вне областей, к которым они были предоставлены определенный доступ.
Таким образом, теория состояла бы в том, что Вы создадите что-то в своем корневом каталоге, затем скопируете его в область, которой Вы управляли (Ваша собственная проектная территория или общая область).
Windows PCs является обычно однопользовательскими системами и не имеет этого ограничения, все входит в Программные файлы несмотря ни на что.
Затем существует глупое, раздражающее то, что каждый раз новая версия Unix вышла, создатели чувствовали это необходимый для изменения местоположений, но старые должны были все еще быть там для автоматизированных сценариев. Это дает Вам набор связанных каталогов, служащих той же цели.
init система еще хуже.
Я просто проверил свою систему CentOS 5 - после:
chgrp kmem /usr/sbin/dmidecode
chmod g+s /usr/sbin/dmidecode
Все еще не возможно получить dmidecode, работающий - у группы kmem есть только права чтения для/dev/mem - кажется, что существует запись, включенная для получения до информации о BIOS.
Так некоторые другие опции:
Для получения общего объема физической памяти можно проанализировать /proc/meminfo
, free
, vmstat
, и т.д. Вы могли также проанализировать буфер сообщений ядра, так как он говорит об этом в 0 раз.
Версия BIOS является более трудной, я не полагаю, что это возможно как некорневой пользователь, но я могу быть неправым. Возможно, что это (и имя системного продукта) выставляется где-нибудь, возможно, в /sys/
или /proc/
, но я ничего не могу найти.
dmesg
если это не было заполнено слишком много. Строка в качестве примера: [ 0.000000] DMI: CLEVO CO. B7130 /B7130 , BIOS 6.00 08/27/2010
– Lekensteyn
09.11.2011, 10:40
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.
На данный момент я собираюсь заменить нашу документацию, указывающую для "использования определенной учетной записи с наименьшим количеством требуемых полномочий" с "пользовательскими корневыми учетными данными".
lshal
содержит большую ту же самую информацию и не требует полномочий пользователя root.
lshal | grep system.product
для имени системы и даже метки лощины с lshal | grep smbios.system.serial
– Mark Booth
07.03.2014, 18:08
Наши услуги Linux не работают как корень. В сценарии установки сообщения об/мин (который ДЕЙСТВИТЕЛЬНО работает как корень) мы устанавливаем/etc/sudo.d файл и setcap несколько наших исполняемых файлов (например, для сети широковещательно передает priviledges).
Попробуйте dmesg. Я смог получить информацию, я хотел этот путь с учетной записью обычного пользователя.
Я не уверен, почему @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
Некоторая информация, представленная dmidecode
, доступна по адресу / sys / devices / virtual / dmi / id
.
Другую информацию можно получить, проанализировав / proc / cpuinfo
, / proc / meminfo
или / sys / system / node / node0 / meminfo
.
Я могу читать информацию DMI как пользователь под /sys/class/dmi/id/
. Не включая серийные номера (для чтения которых требуются привилегии root).
Я полагаю, что это предполагаемое поведение разработчиков ядра с учетом конфиденциальности.
Regarding dmesg
: dmesg
- это команда для доступа к кольцевому буферу ядра. Кольцевой буфер подразумевает, что старая информация перезаписывается более новой, когда буфер "переполняется". Также это чтение отладочного вывода модуля ядра, который никогда не предназначался для разбора.
Для доступа к выводу ядра с помощью systemd
выполните:
journalctl --quiet --system --boot SYSLOG_IDENTIFIER=kernel
По поводу ответов david-homer и nils: Файл /dev/mem
не просто предоставляет информацию о памяти, а отображает всю физическую память в пользовательское пространство. Поэтому через него можно получить доступ к адресам памяти DMI (и делать гораздо более неприятные вещи).
По поводу chgrp
и chmod g+s
из dmidecode
в ответе nils': Полагаю, это не сработает так, как задумано, потому что сохранение gid с помощью chmod g+s
не заставит dmidecode
использовать свои новые привилегии. dmidecode
должен вызвать setegid
, чтобы установить свой эффективный идентификатор группы, прежде чем он сможет получить доступ к /dev/mem
. Судя по исходному коду, dmidecode
этого не делает.