From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 Message-ID: Date: Tue, 15 Oct 2024 09:19:15 +0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel-distro@lists.altlinux.org References: <3cb9b945-2e78-4a53-a142-66054c0d9b9a@gmail.com> <7631577.g5rAFa6ZRE@zerg.malta.altlinux.ru> Content-Language: en-US, ru From: Evgeny Sinelnikov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] =?utf-8?b?0JjQvdGC0LXRgNGE0LXQudGB0Ysg0LTQu9GPINC4?= =?utf-8?b?0L3RgdGC0LDQu9C70Y/RgtC+0YDQsCDQvdCwINCx0LDQt9C1INCw0LvRjNGC?= =?utf-8?b?0LXRgNCw0YLQvtGAIDIuMA==?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2024 05:19:19 -0000 Archived-At: List-Archive: Доброе утро, ответы на вопросы по теме веба, отправлены в отдельном сообщении: - 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. 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