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

[Evgeny Sinelnikov]

Доброе утро,

ответы на вопросы по теме веба, отправлены в отдельном сообщении:
- 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'ом. Но разграничение прав внутри конфигуратора 
> необходимо, и не только в пределах локальных пользователей хоста. 
> Конфигуратор может не ограничиваться одним хостом.

Всё это звучит ("нет нужды разграничивать доступ в установщике"), как 
оторванные от возможной реализации предположения. При этом 
предполагается что-то недостаточно целостное.

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

Давайте рассмотрим несколько принципов:

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

Нам необходимо определиться:

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.* 
интерфейсы.


-- 
Синельников Евгений Александрович
Руководитель обособленного подразделения
«Инженерный отдел «Саратовский» ООО "Базальт СПО"
тел. +7 (495) 123-47-99 (доб. 531)
моб. тел. +7-917-207-53-96