Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein <klark.devel@gmail.com>]

On 10/15/24 08:19, Evgeny Sinelnikov wrote:
> Доброе утро,
>
> ответы на вопросы по теме веба, отправлены в отдельном сообщении:
> - 
> https://lists.altlinux.org/pipermail/devel-distro/2024-October/003050.html
>
> Ниже предлагаю продолжить разбор по поводу интерфейсов.
>
>
> 15.10.2024 01:23, Leonid Krivoshein пишет:
>>
>> On 10/14/24 22:57, Evgeny Sinelnikov wrote: 
> [...]
>>
>>>
>>> 14.10.2024 11:17, Sergey V Turchin пишет:
>>>> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:
>>>>
>>>> [...]
>>>>>> От
>>>>>> механизма, в котором нет, по сути, определенных интерфейсов, к
>>>>>> механизму, где их можно задавать, фиксировать, контролировать доступ
>>>>>> на уровне каждого отдельного метода и получать возможность написания
>>>>>> фронтендов, не требующих выполнения под рутом.
>>>>> При этом установить ОС можно только под рутом. И тогда непонятно, 
>>>>> зачем
>>>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
>>>> Если помните, текущий aterator умееет и пользовательские 
>>>> настройки(реально
>>>> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас
>>>> востребовано.
>>>>
>>>> [...]
>>>
>>> Удивительное дело. Давайте не будем путать. Общая тенденция создания 
>>> безопасных систем приводит к очень сложным в сопровождении решениям, 
>>> вроде SELinux. Проблема в том, что приложения под рутом невозможно 
>>> проконтролировать иначе. Любое приложение под рутом может всё. И 
>>> остаётся только доверять коду и надеяться на то, что этого кода 
>>> будет немного и в нем не будет критических уязвимостей.
>>>
>>> Текущий Альтератор построен на концепции общего набора механизмов 
>>> конфигуратора, как в инсталляторе, так и в установленной системе. 
>>> Недоработка текущей реализации в этом плане привела к тому, что 
>>> графический интерфейс мы вынуждены запускать под рутом. И это, я 
>>> полагаю, напрямую связано с тем, что кем-то тоже было сказано или 
>>> подумано нечто подобное:
>>>
>>> "При этом установить ОС можно только под рутом. И тогда непонятно, 
>>> зачем
>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения."
>>>
>>
>> Совершенно верно. Нет нужды разграничивать доступ в установщике. Нет 
>> необходимости запускать графическую часть установщика или 
>> конфигуратора под root'ом. Но разграничение прав внутри конфигуратора 
>> необходимо, и не только в пределах локальных пользователей хоста. 
>> Конфигуратор может не ограничиваться одним хостом.
>
> Всё это звучит ("нет нужды разграничивать доступ в установщике"), как 
> оторванные от возможной реализации предположения. При этом 
> предполагается что-то недостаточно целостное.
>

Нет нужды разграничивать доступ в установщике на множество 
пользователей. Установщик запускается под root'ом, и графическая часть, 
если запускается на той же машине, м.б. запущена под обычным 
пользователем. Я просто не вижу смысла обсуждать традиционную 
клиент-серверную архитектуру, это не какое-то делегирование множества 
полномочий разным пользователям.


> "Установщик", в этом смысле, как что-то вне графической части - это и 
> есть набор бекендов + движок исполнения сценариев.
>
> Давайте рассмотрим несколько принципов:
>
> 0) от графического интерфейса мы не отказываемся, а его мы под рутом 
> (даже если бы это был веб-интерфейс) точно запускать не собираемся.
>

Да, это правильный тезис.


> 1) таким образом, графические части и конфигуратора, и инсталлятора не 
> должны работать под рутом.

Логично.


> 2) нет смысла писать множество разных реализаций одних и тех же 
> отдельных бекендов для конфигуратора и инсталлятора.
>

Очень спорный тезис. Нет у нас "множества в установщике". В этой 
переписке уже обсуждались плюсы и минусы.


> 3) часть необходимых dbus-бекендов в рамках systemd и других подсистем 
> уже везде используется.
>
> 4) вне этих бекендов современные Linux-дистрибутивы теряют прикладную 
> актуальность.
>

А можно чуть подробнее эти два пункта с примерами? Так не очень понятно.


> 5) придумывать свой дополнительный протокол, когда уже придуман 
> varlink (посмотрим, как пойдёт переезд на него в systemd) тоже пока не 
> имеет смысла.
>

Протокол вообще не нужен, когда в рамках модуля (или кода, 
обеспечивающего некую функциональность) выполняется внутреннее 
разделение на представление интерфейса, данных и исполнительную часть. 
Ты как хочешь, так и организовываешь внутреннее взаимодействие между 
своими частями модуля. Никому больше, кроме самого модуля, дёргать эту 
функциональность не надо, нет смысла для этого навязывать общий протокол 
в обязательном порядке.


> 6) сейчас важнее заниматься бекендами...
>
> Текущие интерфейсы, которые и так есть у всех (с точностью до DE):
>
> $ busctl call org.<TAB><TAB>
> org.blueman.Mechanism
> org.bluez
> org.cinnamon.SettingsDaemon.DateTimeMechanism
> org.freedesktop.Accounts
> org.freedesktop.Avahi
> org.freedesktop.ColorManager
> org.freedesktop.DBus
> org.freedesktop.DisplayManager
> org.freedesktop.Flatpak.SystemHelper
> org.freedesktop.fwupd
> org.freedesktop.GeoClue2
> org.freedesktop.hostname1
> org.freedesktop.locale1
> org.freedesktop.login1
> org.freedesktop.ModemManager1
> org.freedesktop.NetworkManager
> org.freedesktop.oom1
> org.freedesktop.PackageKit
> org.freedesktop.PolicyKit1
> org.freedesktop.realmd
> org.freedesktop.RealtimeKit1
> org.freedesktop.sssd.infopipe
> org.freedesktop.systemd1
> org.freedesktop.timedate1
> org.freedesktop.UDisks2
> org.freedesktop.UPower
> org.gnome.RemoteDesktop.Configuration
> org.kde.drkonqi
> org.kde.fontinst
> org.kde.kcontrol.kcmclock
> org.kde.kcontrol.kcmkwallet5
> org.kde.kcontrol.kcmlightdm
> org.kde.ksysguard.processlisthelper
> org.kde.ktexteditor6.katetextbuffer
> org.kde.ktexteditor.katetextbuffer
> org.kde.powerdevil.backlighthelper
> org.kde.powerdevil.chargethresholdhelper
> org.kde.powerdevil.discretegpuhelper
> org.opensuse.CupsPkHelper.Mechanism
>

В случае d-bus мы можем что-то готовое использовать, чтобы "дёргать", в 
том числе "на лету". Но давайте уж тогда сразу оговорим рамки, где это 
нам удобно и выполнимо, а где наоборот.

D-bus прекрасен, когда нам нужно запустить трек, узнав, что плеер "на 
шине", а он может отправить название трека через тот же d-bus системному 
notifyd. Таких задач в конфигураторе нет, но это основное назначение 
шины IPC в desktop-среде.

Свой d-bus, отдельный от общесистемного... но зачем? Кто и для чего 
будет к этой шине подключаться? В плане безопасности у него и так уже 
есть не только системная, но и отдельная для пользовательского сеанса.

Всё ли в наших ОС завязано на d-bus? Нет. А раз нет, то мы не сможем 
управлять вообще всем через d-bus. Или конфигуратор будет только для 
управления чем-то d-bus'ким? Или мы всё не d-bus'овское будем как-то 
сначала оборачивать в d-bus'овское?

Допустим, мы хотим подтянуть функционал настройки сети в свой 
конфигуратор и продублировали для этого диалоги NetworkManager (прям как 
в установщике Fedora). Мы можем использовать в этом случае d-bus через 
org.freedesktop.NetworkManager, это как проводить операцию через одно 
место автогеном, ведь есть же простой текстовый файл. Я не ярый 
противник d-bus, просто всё, что можно сделать без него, лучше так и 
сделать. Например, я бы отдавал предпочтение работе с простыми 
конфигурационными файлами, нежели чем дёргать интерфейсы через d-bus.

Ниже предлагается совершенно разумная область использования d-bus: мы 
можем взять от системы и сообщества то, что уже готово.


> Нам необходимо определиться:
>
> 1) Какие интерфейсы из системных (доступных в сизифе) мы переиспользуем?
>
> 2) Какие из них мы переписываем?
>
> 3) Какие адаптируем под наш стек (tcb, libnss-role, ...)?
>
> 4) Какие дополняем собственными, поскольку системных (доступных в 
> сизифе) пока что не существует?
>
> ______________________
>
> Мешать в одну кучу системные механизмы и удалённый доступ - очень 
> странная и непонятная затея.
>
> Что придумано и уже в основных деталях реализовано для удалённого 
> доступа?
>
> Реализован механизм (alterator-module-remote), позволяющий 
> автоматизировать удалённое подключение по ssh к объектам и интерфейсам 
> через:
> - 
> https://www.freedesktop.org/software/systemd/man/latest/systemd-stdio-bridge.html
>
> Работает по ключам и krb5-кредам в юзера (если в рута по ключу, так 
> ещё проще, но тогда невозможно ограничить доступ), пробрасывает 
> запросы polkit'а по сети. В ближайшее время пакеты поедут в сизиф. Так 
> что одним хостом оно не ограничивается.

Теперь не ограничивается. Но это значит, что любой изначально не 
приспособленный для этого механизм можно как-то приспособить. И всё же 
любопытно, чем этот опыт закончится.


> Alterator-browser (а также alteratorctl, др.) можно будет запустить на 
> другом узле. Но старые legacy-модули так не получится пробросить.
>
> Реализовано на сессионной шине-dbus, соответственно работает из-под 
> кредов доступных пользователю.
>
> В ближайшее время планируется начать отладку удалённого доступа в 
> alteratorctl.
>
> Кроме того, cockpit и аналогичные возможности выставления этого же 
> набора интерфейсов иным образом никто не отменяет.
>
> PS: Финальные релизы всего в ближайшее время планируется оформить на 
> шине, как /org/altlinux/alterator/* объекты и org.altlinux.alterator.* 
> интерфейсы.
>

Как уже говорил, труды вокруг d-bus не будут напрасными, просто нужно 
ориентироваться на то, чтобы брать от системы по-максимуму готового, а 
не заставлять разработчиков бэкендов описывать всё через d-bus, добавляя 
к guile ещё один новый барьер сложности. Не нужно стремиться плодить 
фронтенды и бэкенды, тогда и единых интерфейсов между ними не потребуется.


-- 
WBR, Leonid Krivoshein.