очередной not-a-bug

синк на семах, данные в шмем, все под капотом либы, прозрачно, прочел (ивент и данные получил), записал (заслал)

очередной not-a-bug (комментарий)

условная аутентификация в зависимости от содержимого сообщения (то, что сейчас dbus+polkit)

активация процесса по запросу (при отправке ему сообщения)

рассылка событий мультикастом

Вот это всё где?

почему это лучше

без сервиса посредника

«— Чем лучше? — Чем грузины.»

вот это все где?

я описал инструментарий, поверх которого и реализуй все эти свои и не только свои «бизнес»-сущности и «бизнес»-поведения.

грузины

тебя спросили, херли дибас там сам по себе живет, ты затребовал на это пример, мол, а как без такого, я тебе привел такой пример, причем тут грузины? сливаешь!

я описал инструментарий, поверх которого и реализуй

Ты утверждаешь, что некий инструментарий подойдёт для решения некой задачи. Будь добр обосновать, что он правда подойдёт и что с его помощью задача вообще решаема, причём решаема целиком, а не только та её часть, которая тебе удобна.

тебя спросили

В этом треде меня ничего не спрашивали.

обосновать

было:

клиент1 <-> дибас <-> клиент2

стало:

клиент1 <-> клиент2

ты же вроде умный, не изображай идиота.

меня не спрашивали

выходит, ты с потолка пример без дибаса-посредника затребовал?

войда больше нет

не изображай идиота

Не изображай шланга. Если ты взялся утверждать, что для решения тех же задач, что решает дбас, не нужен процесс-посредник, и якобы можно обойтись без него, тебе придётся показать, что таким образом достижима вся полезная функциональность дбаса (а не тупо передача сообщений). Какая именно — я привёл выше.

выходит, ты с потолка пример без дибаса-посредника затребовал?

Я затребовал, потому что там кто-то выше начал говорить, что «без посредника лучше». Я усомнился в том, что без посредника вообще возможно.

не изображай шланга
вся полезная фц-сть дибаса

аааа, так ты и правда не понимаешь почему это сработает? сем и шмем используются только для синка и как перевалочный пункт, все остальное же решается в либе - запросить список каких-то имен кому мультикастить, аус в зависимости от сообщения и прочее бизнес-говно.

я затребовал

ну вот, без посредника не только лучше но и возможно.

Где?

Имя юзера в конфигах :)

Во-первых, память.

А батарейка-то тут причем?

Во-вторых, не любой процесс ничего не ест — софт может просто по роду деятельности жрать ресурсы (например, демон, который что-то там поллит или слушает и экспортирует в виде свойств на шину — его не нужно держать запущенным, если нет потребителей этой информации).

Это слишком редкий кейс, чтобы из-за этого CVE огребать.

В-третьих, наконец, софт бывает кривой или неоптимально написанный.

Ну традиционное бизнесовое «вася, лядь, надо СРОЧНО ЧТОБЫ РАБОТАЛО ЗАВТРА РЕЛИЗ ДАВАЙ УЖЕ КАК-НИБУДЬ».

Зачем системе инициализации иметь средства интроспекции и в частности позволять другим программам получать список того, что запущено? Действительно, зачем. Деды парсили /proc и мы будем.

Не очень понимаю, как связано парсенье /proc и получение списка юнитов. Хотя самый лулз в том, что по факту, процессу, который занимается роутиногом сообщений, РУТ ВНЕЗАПНО НЕ НУЖЕН. Просто чуваки из systemd пока не осилили privilege separation.

Это слишком редкий кейс, чтобы из-за этого CVE огребать.

Нет, это достаточно частый кейс.

из-за этого

Ты случайно три страницы рассуждений. Как шинная активация связана с CVE?

Не очень понимаю, как связано парсенье /proc и получение списка юнитов.

Подумай, ты же умный. (c)

Хотя самый лулз в том, что по факту, процессу, который занимается роутиногом сообщений, РУТ ВНЕЗАПНО НЕ НУЖЕН.

Кто-то запускает dbus-daemon от рута?

Нет, это достаточно частый кейс.

ТЫ СКОЗАЛ?

Подумай, ты же умный. (c)

Не, серьезно, давай, кто и когда через /proc получал список запущенных юнитов. Очень хочу услышать.

Кто-то запускает dbus-daemon от рута?

Осталось понять, причем тут dbus-daemon.

ТЫ СКОЗАЛ?

В эту игру можно играть вдвоём. Обоснуй «слишком редкость».

Не, серьезно, давай, кто и когда через /proc получал список запущенных юнитов

Не шлангуй. Там, где раньше парсили /proc, чтобы понять, а запущена ли $хрень, теперь делают org.freedesktop.systemd1.GetUnit.

Осталось понять, причем тут dbus-daemon.

<…> процессу, который занимается роутиногом сообщений <…>

Не шлангуй. Там, где раньше парсили /proc, чтобы понять, а запущена ли $хрень, теперь делают org.freedesktop.systemd1.GetUnit.

Расскажи пожалуйста, как из /proc можно вытащить информацию о том, является ли процесс юнитом какого-нибудь sysv init или openrc? И кто вообще так делал вместо вызова rc-status?

<…> процессу, который занимается роутиногом сообщений <…>

Ага. Смотри, программа X выставляет наружу dbus интерфейс. dbus-daemon доставляет ей сообщения, а она отправляет какие-то сообщения ему. В идеальном мире, программа X разделена на несколько процессов, и каждый из них анально ограничен (например, тому процессу, что принимает/отправляет dbus сообщения, не нужно уметь ничего, кроме как в сокет писать/читать). В systemd гроб гроб клабдище root.

Расскажи пожалуйста, как из /proc можно вытащить информацию о том, является ли процесс юнитом какого-нибудь sysv init или openrc?

Мной этого не утверждалось. Ты сам себе придумал чушь и сам её опроверг.

В идеальном мире, программа X разделена на несколько процессов, и каждый из них анально ограничен (например, тому процессу, что принимает/отправляет dbus сообщения, не нужно уметь ничего, кроме как в сокет писать/читать)

А тому процессу, который собственно выполняет привилегированную работу, коммуницировать с прослойкой нужно как? Через астрал?

В идеальном мире можно хоть каждую функцию в отдельный процесс вынести. Но в реальном мире такие слоёные матрёшки создают кабы не больший attack surface, чем убирают.

Мной этого не утверждалось. Ты сам себе придумал чушь и сам её опроверг.

Не шлангуй. Там, где раньше парсили /proc, чтобы понять, а запущена ли $хрень, теперь делают org.freedesktop.systemd1.GetUnit.

Ахахахаха.

А тому процессу, который собственно выполняет привилегированную работу, коммуницировать с прослойкой нужно как? Через астрал?

Через что-то, что не подразумевает возможности обосраться так сильно. Например, статическими сообщениями через UDS.

В идеальном мире можно хоть каждую функцию в отдельный процесс вынести. Но в реальном мире твои слоёные матрёшки создают кабы не больший attack surface, чем убирают.

Ну расскажи это парням пишушим Chrome и OpenBGPD.

Можно подумать, ты SysVinit’ом управлять собрался.

А там нечем управлять. Упрощенно это дергалка скриптов по симлинкам. Вся сложность в самих скриптах. В системд сложность вынесли в блоб, при любой непонятной ситуации остается только писать письма поттерингу. Отличная схема для конторы кормящейся на техподдержке.

Кек в том, что даже в bsd все поняли и сделали rc из пяти строк, со строго определенным набором переменных. Почему в лялепсе все так дрочат на sysv? Он же страшен был как атомная война.

headers are «leaking»

что это значит?

Нет, воинствующих илитариев никто не слушает, потому что дипломаты из них никакие.

Через что-то, что не подразумевает возможности обосраться так сильно. Например, статическими сообщениями через UDS.

Кэп подсказывает, что поскольку общий объём работы не изменяется, суммарная вероятность обосраться по дороге вряд ли уменьшится (а на самом деле даже увеличится, так как вместо одного протокола у тебя теперь два).

Так что ты не ответил на главный вопрос: парсер, который в таком сетапе будет делать основную часть работы по преобразованию сложных сообщений в простые, похачить (и, получив управление, попросить демона с привилегиями сделать rm -rf /) будет нельзя, потому что…?

был добавлен в systemd-machined в 2015 году в версии systemd 220 (в RHEL 7.x используется systemd 219).

чуть-чуть не долетело.

RHEL 8

эти еще нигде не установлены толком.

вобщем ничего удивительного. сложная система - периодические баги.

Ну косяк то автора, а ты что делать будешь?

А что с ним случилось?

Ага. В инит скриптах, например, в дебиане, надо увеличить лимит открытых файлов. Других вариантов, как вставить в скрипт ulimit у нас нет. Ну, можно, наверное, в rc.local, но тогда это ко всему будет относиться. Далее этот написанный инит менеджер пакетов будет всегда пытаться перезаписать. Во всяком случае будет спрашивать. Поэтому ты его не меняешь. Но автор скрипт подправит, что-то улучшит. Тебе придётся забирать и править заново. Не скажу, что часто это приходится делать, но доставляет. Плюс ко всему зависимости. По факту руления зависимостями нет. Там всё завист от того в каком порядке симлинки установлены. Есть тулзы, которые ставят в зависимости от эти симлинки. Но они на конретный юнит распространяются. Если мы что-то в системе переделаем, то перерасчёт зависимостей для каждого юнита выполнен не будет.

Прикинь, а некоторые на всем пишут нечитаемую лапшу — достаточно расспросить тех кто потом за ними это «со-портит».

нотабаг!

Потому что изоляция ему этого сделать не даст.

Почему в лялепсе все так дрочат на sysv? Он же страшен был как атомная война.

Мне тоже sysv не очень, вот в слаке инит самый труевый. Но после системд уже любой sysv сладок. Короче, слаку и старый дебиан я еще мог сам админить, а теперь только специально обученную макаку нанимать, я на себя ответственность за сабжевую балалайку не возьму ни в жисть. Лялепс теперь не для любителей, теперь тут сурьезный бизнес почти как с маздаем.

войда больше нет

Эт как?

Не даст сделать что конкретно? Не даст какеру поломать парсер (сложность которого не изменится)? Или не даст сформировать совершенно произвольное (в т. ч. вредоносное) сообщение следующему участнику матрёшки (тому, который с привилегиями)?

Что такое «вредоносное сообщение»?

Это такое сообщение, которое заставит привилегированный демон выполнить вредоносную операцию.

Если у демона нет сложной асинхронной обработки на сях (хотя зачем писать на сях в 2к19 это отдельный разговор) с парсингом, то это маловероятное событие.

это когда ты пишешь #include "foo.h", а тебе прилетают все заголовочники когда-либо написанные человечеством.

Нет, не в смысле «по цепочке сломать привилегированный демон», а в смысле попросить его сделать что-то совершенно штатное, но при этом вредоносное. Ну например запустить контейнер с / в качестве корневой ФС и rm -rf / в качестве порождающего процесса.

Нет, не в смысле «по цепочке сломать привилегированный демон», а в смысле попросить его сделать что-то совершенно штатное, но при этом вредоносное. Ну например запустить контейнер с / в качестве корневой ФС и rm -rf / в качестве порождающего процесса.

Что-то мне подсказывает, что доступ к / для процесса, запускающего виртуалки, слегка избыточен.

Опять включаешь шланга. Это уже другой вопрос, нужны ли там привилегии как таковые. Если не нужны, то и изолировать нечего. А если нужны, то твоя матрёшка тебя не спасёт.

Нет, это называется «модель угроз». Я понимаю, что КОКОКО СВЯТОЕ СИСТЕМД покричать хочется, но по факту, изоляцию привилегий все начали делать не просто так.

это называется «модель угроз»

Каким боком модель угроз к обсуждению?

КОКОКО СВЯТОЕ СИСТЕМД

Уровень аргументации «ЛОР».

изоляцию привилегий все начали делать не просто так

Ну вот тебя и просят рассказать, как именно твоя изоляция матрёшкой конкретно здесь поможет. Пока что выходит, что не поможет.

не то что бы хочется убедить, но попробую через аналогию донести - каких-то сто лет назад, может чуть больше, извозчики люто сетовали на вытесняющих их с привычных мест автомобили, находили уйму недостатков у них, что они часто ломаются и т.д. Тебе дальше рассказывать, что стало с извозчиками и к чему привел прогресс автомобилестроения?

я могу принять системный подход, типа systemd продвинутый инструмент для решения определённого рода задач. это ок.

для примера можно привести mikrotik, оно хоть и проприетарщина, но ценится многими одминами просто потому, что ты её подключил, один раз настроил и забыл. она работает годами. тебе не надо бегать на это место, обслуживать железо, софт. сломалось — поменял на другую такую же копеечную коробочку. всё. нишевое решение для всех.

используя тот-же подход можно принять systemd, что она будет просто работать и не требовать к себе лишнего внимания. вот только это далеко не так. пердолиться с systemd в процессе настройки приходится очень много. а когда возникнет проблема, и бизнес встанет, руководство не будет волновать в чём причина, они будут просто «любит» ответственного за это человека.

поэтому в данном случае я бы ни за что не доверил контроль над системой такому сложному комбайну как systemd. который тупо неизвестно что там делает внутрях системы. контроль над системой должен держать системный администратор. а не systemd, который сегодня сервис запустит, а завтра нет.

каких-то сто лет назад

Ну за сто лет системд допилят наверно.

контроль над системой должен держать системный администратор. а не systemd, который сегодня сервис запустит, а завтра нет.

А systemd обладает разумом и срать хотел на конфиги?

Грош цена такому «системному администратору», у которого systemd «сегодня сервис запустит, а завтра нет».

<…> который тупо неизвестно что там делает внутрях системы

Не стоит перекладывать на других свою функциональную неграмотность.

условная аутентификация в зависимости от содержимого сообщения (то, что сейчас dbus+polkit)

зачем это?

активация процесса по запросу (при отправке ему сообщения)

зачем это??? ну и если уж хочется то xinetd например, его можно и на unix socket посадить, можно запилить на named pipe - только вот нахрена это надо?

рассылка событий мультикастом

ты серьезно? зачем это?

из тобой перечисленного в системе инициализации максимум второй пункт, но он без dbus легко делается.

чтобы я мог от пользователя сделать systemctl start foo, но не мог systemctl stop bar (разумеется, без костыляния своих обёрток, в которых вероятность налажать при разборе аргументов — 100%)

вот давай не надо тут а? уже не раз pid 1 падал из-за залаженного разбора аргументов из dbus сообщения - самый известный это tweet ddos, там одной строчкой убивался dbus. хочешь это делать нормально - дополнительный сервис на сокет и тулзы, аутентификацию можно по разному сделать. но это явно не в pid1

чтобы всякие не всегда нужные демоны запускались только когда они нужны, и не жрали батарейку всё оставшееся время

без dbus это делается, xinetd плюс если уж надо можно и по другому сделать, просто никому это не нужно было, всем хватало xinetd.

чтобы приложения могли следить за тем, что происходит в системе (разумеется, без поллинга, в котором вероятность налажать и допустить race condition — 100%)

нахера? а теперь еще расскажи чем твой dbus лучше поллинга?

переходим на новый уровень? ну там где макают dbus?

PS я не против dbus для изначального его применения т.е. Desktop BUS. там ему и место.

Это самое очевидное для упрощения кода, ибо оно позволяет decoupling.

ты dbus вообще видел? где там упрощение то ?

зачем это?

зачем это???

зачем это?

Затем, что это уже есть в D-Bus и этим уже все пользуются.

Сказки про «не нужно» можешь оставить при себе.

Затем, что это уже есть в D-Bus и этим уже все пользуются.

все

не надо тут за всех заливать, и даже за большинство не надо, сказки про нужно можешь оставить также при себе.

Все, кто пользуется D-Bus, разумеется. Шланговать бесполезно.

ты dbus вообще видел? где там упрощение то ?

А ты сам понимаешь что такое dbus?

без dbus это делается, xinetd

Конечно, без dbus это делается. Только (x)inetd — это тоже процесс в юзерспейсе, а мы обсуждаем, можно ли сделать эквивалент dbus без процесса в юзерспейсе.