Sbinmerge: различия между версиями

Материал из ALT Linux Wiki
(→‎Rationale: execve is a syscall and does not traverse PATH)
Строка 40: Строка 40:


== Proposed changes ==
== Proposed changes ==
Пока что никаких.
* Необходимо выявить все скрытые конфликты пакетов между собой и исправить их: https://bugzilla.altlinux.org/54344
* Необходимо выявить и исправить пакеты имеющие внутренние конфликты:
** Пакеты, имеющие в {{path|/usr/bin}} и {{path|/usr/sbin}} разные исполняемые файлы (пакет {{pkg|passwd}}). В таких ситуациях следует перенести исполняемые файлы из {{path|/usr/sbin}} и {{path|/usr/bin}} в другое место, заменив их скриптом запуска, запускающий тот или иной бинарный файл в зависимости от того, кто его запускает (пользователь или root).
** Пакеты, использующие consolehelper. Их необходимо переводить на использование polkit (уже сделано). Если пакет не может быть переведён на polkit (beesu такой случай), то нужно перенести исполняемый файл из {{path|/usr/sbin}} в {{path|/usr/libexec}} и поправить путь в console.apps до программы.
** Пакеты, имеющие разные одноимённые симлинки в {{path|/usr/bin}} и {{path|/usr/sbin}}. Таким пакетом является sendmail-common mailq ({{path|/usr/bin/mailq}} -> {{path|../sbin/sendmail}}; {{path|/usr/sbin/mailq}} -> {{path|sendmail}}); newaliases ({{path|/usr/bin/newaliases}} -> {{path|../sbin/sendmail}}; {{path|/usr/sbin/newaliases}} -> {{path|sendmail}}). Сам {{path|/usr/sbin/sendmail}} в postfix, sendmail-submit, ssmtp.
** Пакеты, имеющие симлинки в {{path|/usr/sbin}} на {{path|/usr/bin}} и наоборот. При установке таких пакетов на уже смерженные системы может произойти непоправимое, установится симлинк, а не исполняемый файл. Поэтому симлинки должны быть заменены на хардлинки. Это может быть сделано автоматически. Примерный список таких пакетов:
  alterator: alterator-cmdline
  alternatives: alternatives-update
  bonnie++: bonnie++
  net-tools: arp ifconfig route
  iproute2: ip lnstat nstat rtmon ss tc
  fbset: fbset modeline2fb
  psmisc: fuser (/usr/bin/fuser -> ../../sbin/fuser)
  iftop: iftop
  systemd: systemctl
  lshw-gui: lshw-gui
  lsof: lsof (/usr/bin/lsof -> ../sbin/lsof)
  makemap: makemap
  squashfs-tools: mksquashfs
  udev: udevadm
  usbip: usbip


== Incompatibilities ==
== Incompatibilities ==

Версия от 11:00, 29 мая 2025


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, ...
  • Сборочным скриптам и прочим интеграционным программным компонентам не нужно будет перебирать каталоги, в которых находится искомая программа. (Возможно, самый частый случай такого перебора — execvp(3))
  • Какой-нибудь толстый и важный апстрим (systemd) может прекратить поддержку unmerged-bin, и патчсет для сохранения корректной поддержки может оказаться слишком большим, создавая чрезмерную нагрузку на мейнтейнера.

Proposed changes

  • Необходимо выявить все скрытые конфликты пакетов между собой и исправить их: https://bugzilla.altlinux.org/54344
  • Необходимо выявить и исправить пакеты имеющие внутренние конфликты:
    • Пакеты, имеющие в /usr/bin и /usr/sbin разные исполняемые файлы (пакет passwd). В таких ситуациях следует перенести исполняемые файлы из /usr/sbin и /usr/bin в другое место, заменив их скриптом запуска, запускающий тот или иной бинарный файл в зависимости от того, кто его запускает (пользователь или root).
    • Пакеты, использующие consolehelper. Их необходимо переводить на использование polkit (уже сделано). Если пакет не может быть переведён на polkit (beesu такой случай), то нужно перенести исполняемый файл из /usr/sbin в /usr/libexec и поправить путь в console.apps до программы.
    • Пакеты, имеющие разные одноимённые симлинки в /usr/bin и /usr/sbin. Таким пакетом является sendmail-common mailq (/usr/bin/mailq -> ../sbin/sendmail; /usr/sbin/mailq -> sendmail); newaliases (/usr/bin/newaliases -> ../sbin/sendmail; /usr/sbin/newaliases -> sendmail). Сам /usr/sbin/sendmail в postfix, sendmail-submit, ssmtp.
    • Пакеты, имеющие симлинки в /usr/sbin на /usr/bin и наоборот. При установке таких пакетов на уже смерженные системы может произойти непоправимое, установится симлинк, а не исполняемый файл. Поэтому симлинки должны быть заменены на хардлинки. Это может быть сделано автоматически. Примерный список таких пакетов:
 alterator: alterator-cmdline
 alternatives: alternatives-update
 bonnie++: bonnie++
 net-tools: arp ifconfig route
 iproute2: ip lnstat nstat rtmon ss tc
 fbset: fbset modeline2fb
 psmisc: fuser (/usr/bin/fuser -> ../../sbin/fuser)
 iftop: iftop
 systemd: systemctl
 lshw-gui: lshw-gui
 lsof: lsof (/usr/bin/lsof -> ../sbin/lsof)
 makemap: makemap
 squashfs-tools: mksquashfs
 udev: udevadm
 usbip: usbip

Incompatibilities

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

User-visible impact

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

Appendix