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=1728941003; x=1729545803; 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=lwdd4sA7afcxsaCE4MzUs+zrWAbUaUB2Bd5rrj2sl98=; b=BVukMD0wBSszJBYZZHchbWTiVV12g/VaKbljpCVmmbNbd19oYVuS77vQCdxSFws/Ap 2TU4baipr0FRZ6Fgh/WLiC9BygSi5F6KjvF0RE3FoxqpBS7/bmuG6MkKaXALNLi+mhEt pIh1W+hUXDh7zpnWo8Yo2H6KIh7lJdp7Plo9Ju9PI2OWMuitNRbGYhAYqfHxBctrFmKI jpAKtpm+bKcVNLxyA5EyVsVNGOv5KhIQDAnzvv2kxF+Pt62HfXkF/RzpQX0YoIE/dlm6 VizYXA7/n9BCZkKa8chDPZ4fT9YeJi6tb06bbJYCozB0QoMW/+GQWYshr7y3Vyza+Kw0 eRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728941003; x=1729545803; 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=lwdd4sA7afcxsaCE4MzUs+zrWAbUaUB2Bd5rrj2sl98=; b=DVaTpBhtd6ZGUqvKoONgiMMml0uowKPMpoJ9YMmnvdSuNLPDIhuF5Gq/JpsWITtWKa 0UlxZWiaBsQQPoSYw0MzCfEvSHMtnzrrhb3Yd6x2a0sruXqxH3D9lXmUqHLww4S/5JRk 9+PrgY7KzaVw+YEhbk2bf00wJqepR4pbh2k9ZxffYj49QxXs5ylZ8KQc9BypdlWxBUSp ibEvnAUW0O2wnMRVZY32l7EGV4FRYR28qWNmN3KLvj93YPXxZXdfKGbGh+wZRjbPhn93 M2OjlI82Y5WCrjcJVdvkdjsdXjv4ihKBHwGUtHGx3LawnsKsjIa2t6wFZeH2wkbCkGof 5kEw== X-Gm-Message-State: AOJu0Yx/njH4IVlhVvN6jAeHtpK0AS/+aegjawI0r3XyW8M9jJMMszss l+u1e0iyigGn9vpv5vTSyM3wDpqH1rGGinBsj8bKpgmYuM6AdCmf9c4R3w== X-Google-Smtp-Source: AGHT+IG2tVTttB9SyzVkeHMHebAtijt/7Oa4Pc+QfIT6ll9EtJFWpWwhJwwi1Ll5PNzj2J10ZJ0F+g== X-Received: by 2002:a05:6000:128f:b0:37d:364c:b410 with SMTP id ffacd0b85a97d-37d55304616mr10005393f8f.33.1728941003105; Mon, 14 Oct 2024 14:23:23 -0700 (PDT) Message-ID: Date: Tue, 15 Oct 2024 00:23:21 +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: Mon, 14 Oct 2024 21:23:27 -0000 Archived-At: List-Archive: 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'ом. Но разграничение прав внутри конфигуратора необходимо, и не только в пределах локальных пользователей хоста. Конфигуратор может не ограничиваться одним хостом. > То есть упор был на инсталлятор, а конфигуратор остался как есть. А > концепт, одних и тех же модулей сохранился. > > Сейчас мы идём от обратного. Сначала конфигуратор, а потом > инсталлятор. Хоть под рутом, хоть не под рутом. С другой стороны, а в > чём, собственно, переусложнение? > > Один из вариантов запуска нашего текущего инсталлятора - это запуск > его, как приложения, в обычном livecd. В большинстве дистрибутивов оно > так и работает. В графическом виде. При этом консольного (не > графического) инсталятора у нас так пока и не было сделано. > > А, если нам нужен графический инсталлятор, то графику, в любом случае, > не стоит запускать под рутом. Да. Конфигуратор я бы рассматривал как веб-интерфейс, работающий не под root'ом, и не обязательно на том же хосте. Как фоновый агент, через который можно менять настройки системы, будучи администратором сети, у которого есть полномочия, а не только как локальный root. И одной из обязанностей этого фонового агента может быть периодическое обновление куска дерева конфигурации с какого-то условного контроллера домена. Часть настроек может быть изначально в ведении обычного пользователя. В идеале иметь возможность как делегировать пользователям полномочия менять конкретные системные настройки, так и наоборот, забирать у обычного пользователя полномочия менять изначально пользовательские настройки. Всё это разделение прав решается в пределах одной программы конфигуратора без SELinux, Polkit и интроспекции dbus. Как вариант, в пределах иерархической БД конфигурации. К слову, в виндовом реестре, помимо древовидных "кустов" предусматривалась раздача ACL на целый "куст". > ____________________ > > Итого, по теме под рутом, не под рутом. Если будет графика, то не > понимаю что мы обсуждаем. Чем нам графика под рутом жизнь облегчит? > Тем, что shell-скрипты можно будет писать не только на bash, но и на C > или Python? На я имею в виду fork/exec консольных приложений. > > На текущий момент имеется dbus - не вижу ничего противоестественного > использовать его в инсталляторе. Давно стоило акцентироваться, что dbus, прежде всего -- IPC, а зачем нужен IPC в инсталляторе? Это точно кажется противоестественным. И в конфигураторе-то он может быть нужен далеко не в каждом модуле. > Кстати, как альтернативу, с недавних пор systemd рассматривает - > https://varlink.org/ > > Systemd Looking At A Future With More Varlink & Less D-Bus For IPC > https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future > Просто, по нужде люди работают много лет с этим dbus и понимают, что организовать взаимодействие можно намного проще. Причём там, где оно действительно нужно. Например, когда мы связываем фронт с бэком в UI/UX, JSON & Ко уместнее dbus, особенно, если мы выходим за пределы хоста, чего хотелось бы. Если конфигуратор -- одна программа, если наш тулкит уже позаботился о взаимодействии фронт и бэк частей модуля, нам даже не надо об этом думать и остаётся только решить, в каких случаях уместно использовать кем-то написанное с использованием dbus, чтобы подтянуть и этот дополнительный функционал. > В выше приведенной статье указаны многие проблемы, с которыми > сталкиваются в systemd. Они там хорошо структурированы и технически > обоснованы. Возможно, нам тоже стоит к этому присмотреться к systemd > версии 257. > > И это, как раз, то, что предлагалось в рамках всех разумных > альтернатив для dbus. Но... ресурсов спроектировать всё на новом стеке > прямо сейчас пока не наблюдается. > > Предлагаю об этом подумать сразу после написания новых модулей. И, > главное, интерфейсов для них. В смысле бекендов. Сделать к ним > интерфейсы на varlink'е будет не сложно. И проблема необходимости dbus > перестанет быть. > -- WBR, Leonid Krivoshein.