From: Evgeny Sinelnikov <sin@basealt.ru> To: devel-distro@lists.altlinux.org Subject: Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0 Date: Tue, 15 Oct 2024 09:19:15 +0400 Message-ID: <fdba2280-e416-45f4-97b5-e5b0e100b6f7@basealt.ru> (raw) In-Reply-To: <bce5158b-9bb0-40e4-988c-0453c08327ac@gmail.com> Доброе утро, ответы на вопросы по теме веба, отправлены в отдельном сообщении: - 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
next prev parent reply other threads:[~2024-10-15 5:19 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-10-08 13:43 [devel-distro] Тезисы " Антон Мидюков 2024-10-08 23:13 ` [devel-distro] " Leonid Krivoshein 2024-10-08 23:29 ` [devel-distro] Тезисы для инсталлятора " Leonid Krivoshein 2024-10-09 2:13 ` Evgeny Sinelnikov 2024-10-09 21:52 ` Leonid Krivoshein 2024-10-14 7:17 ` [devel-distro] " Sergey V Turchin 2024-10-14 19:57 ` [devel-distro] Интерфейсы " Evgeny Sinelnikov 2024-10-14 21:23 ` Leonid Krivoshein 2024-10-14 21:57 ` Антон Мидюков 2024-10-15 1:11 ` Leonid Krivoshein 2024-10-15 4:49 ` Anton Farygin 2024-10-15 9:44 ` Michael Shigorin 2024-10-15 15:05 ` Denis Medvedev 2024-10-16 0:25 ` Leonid Krivoshein 2024-10-17 7:22 ` [devel-distro] " Sergey V Turchin 2024-10-15 19:29 ` [devel-distro] " Leonid Krivoshein 2024-10-17 7:27 ` [devel-distro] " Sergey V Turchin 2024-10-18 9:05 ` [devel-distro] [JT] мировоззренческое по путям развития Michael Shigorin 2024-10-15 5:19 ` Evgeny Sinelnikov [this message] 2024-10-15 23:02 ` [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0 Leonid Krivoshein 2024-10-15 10:30 ` [devel-distro] инсталятор как краеугольный камень выбора технологического пути Michael Shigorin 2024-10-09 1:40 ` [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл Leonid Krivoshein 2024-10-09 9:06 ` [devel-distro] " Sergey V Turchin 2024-10-09 19:46 ` [devel-distro] " Leonid Krivoshein 2024-10-10 19:29 ` [devel-distro] про API и фронтэнды Leonid Krivoshein 2024-10-10 23:27 ` Антон Мидюков 2024-10-11 0:33 ` Leonid Krivoshein 2024-10-14 7:27 ` Sergey V Turchin 2024-10-15 4:59 ` [devel-distro] Веб-браузер в инсталляторе или для инсталлятора? Evgeny Sinelnikov 2024-10-15 5:53 ` Антон Мидюков 2024-10-15 20:53 ` Leonid Krivoshein 2024-10-18 9:25 ` Michael Shigorin 2024-10-14 7:22 ` [devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Sergey V Turchin 2024-10-14 19:58 ` [devel-distro] " Leonid Krivoshein 2024-10-15 4:52 ` Anton Farygin 2024-10-15 19:30 ` Leonid Krivoshein 2024-10-15 6:33 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:32 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:49 ` [devel-distro] " Антон Мидюков 2024-10-17 8:44 ` [devel-distro] " Sergey V Turchin 2024-10-18 8:56 ` [devel-distro] qtbrowser vs wasm Michael Shigorin 2024-10-15 10:03 ` [devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Michael Shigorin 2024-10-15 23:49 ` Leonid Krivoshein 2024-10-16 8:52 ` Michael Shigorin 2024-10-14 7:43 ` [devel-distro] " Sergey V Turchin 2024-10-14 10:54 ` [devel-distro] " Sergey V Turchin 2024-10-09 9:49 ` [devel-distro] " Alexey Gladkov 2024-10-09 19:54 ` Leonid Krivoshein 2024-10-10 9:10 ` Alexey Gladkov 2024-10-10 12:21 ` Leonid Krivoshein 2024-10-10 14:31 ` Alexey Gladkov 2024-10-09 6:19 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Ivan A. Melnikov 2024-10-09 7:21 ` Антон Мидюков 2024-10-09 9:21 ` [devel-distro] " Sergey V Turchin 2024-10-09 13:08 ` [devel-distro] " Leonid Krivoshein 2024-10-09 13:56 ` [devel-distro] о голосовом управлении (was: Тезисы для инст, альтератор 2.0) Arseny Maslennikov 2024-10-10 8:11 ` [devel-distro] о голосовом управлении Антон Мидюков 2024-10-14 7:33 ` [devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0 Sergey V Turchin 2024-10-09 22:08 ` [devel-distro] " Leonid Krivoshein 2024-10-10 1:01 ` [devel-distro] Пример файла разметки и описания Leonid Krivoshein 2024-10-10 8:54 ` Антон Мидюков 2024-10-10 5:26 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Антон Мидюков 2024-10-10 10:29 ` Leonid Krivoshein 2024-10-14 4:58 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог) Антон Мидюков 2024-10-14 18:59 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=fdba2280-e416-45f4-97b5-e5b0e100b6f7@basealt.ru \ --to=sin@basealt.ru \ --cc=devel-distro@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git