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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729033324; x=1729638124; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=nQcMcs3P7T+ldvvKqVkLLqv3psja85w1dt3Rorh2078=; b=X9zLFm1mmWOwsmlVXpqcwwVGUJECDQuJocvVbTT5VoDn5dA2MomwI+dJ6ZgUaxeWTs h7ysNMguJLcvGDNOVknfNEz1q5UEVaoxu0vXf487UnJoQNM2hxnNoOylUwy/LNZs6Ddx zvIMybQ6od0IndWbTJvcx666HyYjIetOvBdAi2RcEwAdKPNUBi1SauDWrb/9pPQH6wfF j3V2+xvQHTZb1wGg3V6eYtyNW6n1HbI9d1nphiwAQBniaMGfCa6Aju646DQobsi2sxJr TcDcQMtPv+nLtK0+WKZkKruoEz0n5wh9HUMZiiX26vkGwF1EJHfVgQwwT70IRnZsDBqU sZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729033324; x=1729638124; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nQcMcs3P7T+ldvvKqVkLLqv3psja85w1dt3Rorh2078=; b=VgaLCX45D/Zzh1IysoiQcGAiBVW3R9IbPSWEHs/ZpHR1Y0wX2595E7U0UD1JJgAqNH KvM0w9KCT5OJQnIMWUx3P73W4c/rDsbBdORI+jy14LcMMvcpiNeC6Pe1rvkX/KvK5weY 74cjJTGllQFwPu250B2snzwaGIgpQrE5Ub7l8OhLOWbwqRoh/mhX4bC86OPCAThj5QFG cdC0Qa+DKZmwS+eoiwwXPqh8tWwKJchhwIHnT/O5tyepXDGZQlTw8psPzw/8gznQAnQd gDQdJqsaFPfuyMA9R4ynxxhOP9HbIvrN2V6gFoZp7gy7VNfWM9UK8TcYSDf730nWaIQT gblw== X-Gm-Message-State: AOJu0YzMvImDzcgxCIQ4v6oCB/zW+VhYnUu28wqie1TeA3h21LDNn+lX MpLlyPTGMAZ1Ga0M97W14PTfLT5RYN9Tec13+i1E3N6lbKll7c04acyEDw== X-Google-Smtp-Source: AGHT+IHMHZN5GdDLHqmB+QXZv3J/Kv39RjkionwTnrmivsO3jGkme951uSDOXhI3kTd47GaNzms15A== X-Received: by 2002:a5d:44cb:0:b0:37c:ccdf:b69b with SMTP id ffacd0b85a97d-37d552ffd90mr11820304f8f.32.1729033323680; Tue, 15 Oct 2024 16:02:03 -0700 (PDT) Message-ID: <2b32f130-84c8-4427-92a4-351e98194f30@gmail.com> Date: Wed, 16 Oct 2024 02:02:01 +0300 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: ru, en-US From: Leonid Krivoshein 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 23:02:08 -0000 Archived-At: List-Archive: 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. > 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.