Почему иерархия папок в /sys/bus/platform/devices меняется при перезагрузке?

Порядок задокументирован в руководстве по динамическому компоновщику, то естьld.so. Это:

  1. каталоги из LD_LIBRARY_PATH;
  2. каталоги из /etc/ld.so.conf;
  3. /lib;
  4. /usr/lib.

(Я немного упрощаю, полную информацию смотрите в руководстве.)

Порядок имеет смысл, если учесть, что это единственный способ переопределить библиотеку в расположении по умолчанию пользовательской библиотекой. LD_LIBRARY_PATH— это пользовательская настройка, она должна стоять перед остальными. /etc/ld.so.conf— это локальная настройка, она предшествует настройке операционной системы по умолчанию. Итак, как пользователь, если я хочу запустить программу с другой версией библиотеки, я могу запустить программу с LD_LIBRARY_PATH, содержащим расположение этой другой версии библиотеки. И как администратор я могу поместить другую версию библиотеки в /usr/local/libи перечислить /usr/local/libв /etc/ld.so.conf.

Доверие здесь ни при чем. Любой каталог, указанный в этом пути поиска, должен быть доверенным, потому что любая библиотека может быть загружена оттуда. Теоретически вы могли бы перечислить имена библиотек, используемых всеми программами, «требующими большего доверия» в вашей системе, и убедиться, что все эти библиотеки присутствуют в «наиболее надежных» каталогах, и тогда «менее надежные» каталоги не будут использоваться, если они идут после более надежных каталогов на пути поиска, за исключением программ, «требующих меньшего доверия». Но это было бы очень хрупко. Также было бы довольно бессмысленно :, если злоумышленник может внедрить значение LD_LIBRARY_PATHили элемент /etc/ld.so.conf, у него наверняка есть более прямой путь к выполнению произвольного кода, например, внедрение значения PATH, из LD_PRELOADи т. д. Доверие к пути загрузки библиотеки имеет значение, когда выполнение пересекает границу доверия, то есть при запуске программы с дополнительными привилегиями (, например setuid/setgid или черезsudo). Что происходит в этом случае, так это то, что LD_LIBRARY_PATHгаснет.

Что касается /libпротив /usr/lib,это не имеет большого значения :они предоставляются одним и тем же объектом (операционной системой )и не должно быть библиотеки, присутствующей в обеих. Имеет смысл перечислить /libпервым, потому что он обеспечивает (очень маленькое )преимущество в производительности :наиболее -часто -используемые библиотеки, особенно библиотеки, используемые небольшими базовыми программами (для время загрузки которых составляет более высокую долю от общего времени выполнения, чем большая, длинная -работающая программа ), расположены в /lib.

2
27.01.2019, 02:24
1 ответ

/sys/class/hwmon/символические ссылки, кажется, создаются на основе порядка загрузки модулей, что вы можете принудительно включить, занеся их в черный список, а затем вручную загрузив их в желаемом порядке, как указано в этом посте .

Однако conky hwmonна самом деле принимает имя устройства, так что вы можете просто использовать его!

Например, вместо ${hwmon 5 temp 1}я могу сделать ${hwmon coretemp temp 1}.

Далее будет указан текущий номер > сопоставление имен:

for dir in /sys/class/hwmon/*; do echo -n "$dir: "; cat $dir/name; done

sensorsтакже перечисляет имена устройств, но вместе с именем адаптера.


Если вы хотите получить доступ к этим значениям без conky hwmon(, например. для Конки execgraph),это, вероятно, взлом, и я не могу гарантировать его надежность, но :все каталоги, которые /sys/class/hwmon/символически ссылаются на это, имеют пронумерованную папку hwmon, похоже, имеют только одну папку, так что вы можете просто попасть туда с *.

Например, мой /sys/class/hwmon/hwmon5ссылается на /sys/bus/platform/devices/coretemp.0/hwmon/hwmon5, но в /sys/bus/platform/devices/coretemp.0/hwmon/нет других каталогов, поэтому я могу получить доступ к значениям, например, с помощью. cat /sys/bus/platform/devices/coretemp.0/hwmon/*/temp1_input.

0
20.11.2020, 02:51

Теги

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