Sbinmerge

Материал из ALT Linux Wiki
Версия от 16:25, 17 мая 2025; ArsenyMaslennikov (обсуждение | вклад) (Новая страница: «Категория:Sisyphus = Sbinmerge = Пока не планируется в Sisyphus, но при подготовке пакетов лучше уменьшать и не усугублять несовместимость с <tt>merged-sbin</tt>. == Глоссарий == Известно, что файловые объекты в системе сложены в иерархию каталогов. О FHS-подобной иерархии фа...»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)


Sbinmerge

Пока не планируется в Sisyphus, но при подготовке пакетов лучше уменьшать и не усугублять несовместимость с merged-sbin.

Глоссарий

Известно, что файловые объекты в системе сложены в иерархию каталогов. О FHS-подобной иерархии файловых объектов, в которой пути /usr/sbin и /usr/bin взаимозаменяемы (тт. е., фактически, /usr/sbin является ссылкой на /usr/bin), говорят, что она обладает merged-sbin-свойством; в проекте systemd это также называют merged-bin. Иерархия, не отвечающая этому правилу, называется unmerged-sbin; в проекте systemd это называют unmerged-bin.

Введение

Исторически[1] в UNIX System V, а позже и в мейнстримных линукс-дистрибутивах разделяли каталоги /bin и /sbin. Истинная причина различать эти два каталога утеряна.

У этих каталогов есть аналоги под /usr, для них справедливы всё те же рассуждения.

С течением времени этому расхождению стали придумывать разные обоснования.

  • Под /sbin можно помещать критические статически скомпонованные бинарники вроде /sbin/mount и /sbin/mkfs, которые продолжат работать, если в системе сломаны или отсутствуют разделяемые библиотеки.
  • Под /sbin можно помещать исполнимые файлы, предназначенные для запуска только администратором, и указывать /sbin в PATH только аккаунтам root (с uid 0).

Аргумент про статически скомпонованные бинарники не соответствует как практике ALT, так и других GNU/Linux: для этого, например, потребуется убрать из каталога /sbin динамические бинарники и выкинуть его из PATH. Для восстановления системы лучше организовать где-то рядом компактный раздел восстановления, с утончёнными бинарниками, возможно, статическими, ... Для порождения сборочных чрутов hasher применяет статически собранные find и cpio, но кладёт их так, чтобы они не могли попасться в PATH при типичном использовании системы.

Аргумент о инструментах администрирования смотрится интереснее, но провести границу между бесполезными для не-администраторов программами и остальными невозможно, и программы начинают попадать в один из каталогов случайно. Те категории пользователей, что привыкли дополнять PATH какими-то сторонними каталогами с исполняшками из сторонних источников, и вовсе могут получить нежелательные эффекты, добавив или убрав себе /sbin: либо запустится неправильная программа из /usr/sbin, перекрывающая правильную, либо выскочит ошибка "программа не найдена". Часто это заканчивается тем, что пользователи просто добавляют в PATH оба каталога, и разделение фактически не работает.

Более того, и сами инструменты администрирования меняются (ручное управление => ansible, salt, "GitOps", ...)

  • Команда ip — не только инструмент настройки сетевого стека, но и инструмент диагностики (непривилегированной).
  • Команды e2image, mksquashfs и подобные — это инструменты работы в том числе с образами ФС, нередко для дальнейшего применения на других машинах с более крутым уровнем привилегий, чем у пользователя на машине, где образ создаётся.
  • Команды reboot, poweroff, halt при соотв. модели безопасности доступны и непривилегированному пользователю, если у него есть физ. доступ к кнопке "reset" (например, это рабочая станция или персоналка).

И так далее...

Чем сохранять бесцельно дублирующие друг друга два каталога для бинарников из PATH для одних и тех же файлов, лучше оставить один из них, /bin, а другой устранить.

Rationale

  • Один каталог проще двух. Его легче снапшотить, по нему легче гонять find, ...
  • Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа. (Возможно, самый частый случай такого перебора — execve(2))
  • Какой-нибудь толстый и важный апстрим (systemd) может прекратить поддержку unmerged-bin, и патчсет для сохранения корректной поддержки может оказаться слишком большим, создавая чрезмерную нагрузку на мейнтейнера.

Proposed changes

Пока что никаких.

Incompatibilities

TODO: Проверить систему alternatives, что она работает правильно в merged-sbin окружении.

User-visible impact

Исчезнет ситуация, где программа на самом деле находится в /bin, но её вызывают по полному пути в /sbin (или наоборот) и получают ошибку "файл не найден".

Appendix