Sbinmerge: различия между версиями
(→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 (или наоборот) и получают ошибку "файл не найден".