systemd local DoS

А ничего, что udev встроен в systemd? logind тудаже, nss даже! journald, getty, управление питанием.

Ничего из этого не выполняется в PID1.

Ничего из этого не выполняется в PID1.

Обнови что-то из этого без обновления того, что в PID1.

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

BTW, обнови cp, не обновляя mv.

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

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

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

Допустим, я согласен с тем, что это комбайн: там привели какое-то определение и показали, почему PID1 systemd под него подходит.

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

Где ты видел, чтобы в init нашли локальную DoS уязвимость?

Классический System V init не является супервизором и сравнивать их некорректно.

В systemd нечто вроде контейнеров (лол что?!), монтирования дисков, управления сетью, крон, повешены на PID 1.

Чушь. Из этого в PID 1 выполняется только аналог крона.

Если произойдёт ошибка, например в контейнерах, при загрузке то это будет означать Kernel Panic.

Чушь. Во-первых, как я уже сказал, никакого упоминания «контейнеров» в PID1 systemd нет. Во-вторых, в самом худшем случае это будет означать остановку выполнения и emergency shell.

Бинарные логи, они до сих пор не восстанавливаются если файловая система грохнется, не так ли?

Позволь спросить, а какие логи восстанавливаются, если файловая система грохнется? И как они это делают? Если ты предоставишь копию libastral.so, мы ей обязательно воспользуемся.

Леннарт переизобрёл С

Штоа?

strcat(strmem(strmem(strmem

stpcpy, вообще-то.

Ну и напоследок - Леннарт изобрёл велосипед, потому что до него всё работало и даже было куча аналогов SysVInit.

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

А ничего, что udev встроен в systemd? logind тудаже, nss даже! journald, getty, управление питанием.

В systemd не встроено ничего из этого списка.

Обнови что-то из этого без обновления того, что в PID1.

Легко.

cd systemd-X
./autogen.sh
make systemd-journald journalctl
install -m755 systemd-journald journalctl /usr/bin

удобнее пользоваться

Просто некоторым достаточно

*/30 * * * * /etc/init.d/httpd restart

:))

Классический System V init не является супервизором и сравнивать их некорректно.

Справедливости ради, в минимальной степени является. Что-то там насчёт /etc/inittab и respawn.

Весь тред — какая-то конаническая демонстрация неосиляторства нытиков, пришедших из каменного века и захватив с собой полное непонимание современных стандартов качества..

В то время как sysvinit делал *фэйлы* на пустом месте (неправильные запуски демонов, в зависимости от состояния-и-окружения текущего сеанса root-пользователя, который делает вызовы запусков)..

..в systemd вдруг маленькая ошибочка (ни на что не влияющая, в целом) — и эти неосиояторы начали сразу нести срань-пургу и сопли отчаянья :-D .. ахахаха! Прорвало!!

КАРЛ! Sysvinit просто не мог нормально запускать демонов! (И зачастую нормально их останавливать, в зависимости от различных стечений обстоятельств)..

...о каком сравнении качества с systemd тут можно спорить :-D

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

У автомобиля отвалится прикуриватель и вы скажете «вот оно качество автомобиля! А у повозки с лошадью такого бы не произошло!» :-D

Дроби пакет на части, обновляй независимо

Ты не понимаешь сути сборки пакетов. Когда требуется проставлять межпакетные зависимости по %version-%release. Никакое дробление на подпакеты тут не поможет.

Легко.

И, в итоге, у тебя не ОС, а свалка мусора из непонятно, как связанных бинарников в lib и bin, которые работают с непредсказуемым эффектом.

Sysvinit просто не мог нормально запускать демонов! (И зачастую
нормально их останавливать, в зависимости от различных стечений
обстоятельств)..

Враньё. Просто потому, что Sys V init этого не делал вообще.

У автомобиля отвалится прикуриватель и вы скажете «вот оно качество автомобиля!

Если из-за этого прикуривателя сразу же клинит двигатель, то несомненно.

А почему тогда в альте всё это получилось?

Враньё. Просто потому, что Sys V init этого не делал вообще.

s/sysvinit/& + sysvrc/, суть сказанного не меняется.

Вопрос был про то, как обновить одно без другого. Ответ, внезапно, про то же самое. А как это опакетить в рамках твоего дистрибутива — тебе виднее.

А почему тогда в альте всё это получилось?

Это с чего ? Не получилось.
https://packages.altlinux.org/en/Sisyphus/srpms/systemd/spec

Скажем, «%package -n udev»: Conflicts: systemd < %EVR

Или:

%package -n journalctl
Requires: libsystemd-shared = %EVR

Собственно, «Requires: libsystemd-shared = %EVR» есть практически у всех подпакетов, соответственно, обновление одного ведёт к вытягиванию всех.

s/sysvinit/& + sysvrc/, суть сказанного не меняется.

Да, и так не меняется. Они не запускают демоны, они запускают init-скрипты. А уж как написан init-скрипт - это разговор, к sysvinit отношения имеющий только косвенно.

Вопрос был про то, как обновить одно без другого.
Ответ, внезапно, про то же самое.

Ответ, внезапно, на вопрос, как сделать бардак в системе. Так как make install - это последнее, чем следует пользоваться для установки приложений в ОС.

Да, значит, у них тоже не получилось.

Что не отменяет того факта, что можно собрать статически, тогда единственной межпакетной зависимостью будут стабильные DBus-интерфейсы.

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

Вот именно. Стало быть, sysvinit+sysvrc отдают все вопросы корректности, предсказуемости и прочего на откуп скриптописателя. А systemd обеспечивает всё это самостоятельно.

Именно по этой причине сравнение sysvinit(+sysvrc) и systemd — сродни сравнению конной повозки и автомобиля.

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

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

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

А systemd обеспечивает всё это самостоятельно.

И кофе ещё, ещё может кофе. Падая вместе с чайником. Речь про излишние усложнение там, где крайне важна надёжность, а не фичастость.

Не смешно и толсто. Попробуй еще раз.

Если системда через каждую вторую перезагрузку/выключение начинает вести (бесконечный) отсчет до остановки нескольких юнитов из всей кучи, а потом всё же виснет, то ни о какой качественной замене openrc и речи нет.

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

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

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

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

Хорошо, что ты не занимаешься проектированием.

Здесь не хватает обоснования того, что это усложнение действительно излишнее.

Позволь спросить, а какие логи восстанавливаются, если файловая система грохнется?

Plain text лучше восстанавливаются, как ни странно. Их можно хотя-бы частично восстановить. А бинарный даже не прочитается, если в нём изменить несколько байт. Источник: По личному опыту.

«контейнеров» в PID1 systemd нет.

А бинарник systemd теперь разделён на systemd, systemd-nspawn, systemd-crond, systemd-logind, etc.? Или это всё те же ссылки на один бинарник?

в самом худшем случае это будет означать остановку выполнения и emergency shell.

А рут то не смонтировался =) Ну бизибоксовский выполнится, если повезёт. Но вот с SysVInit у меня такого никогда не было, а как падал systemd вместе с ядром я видел лично.

Штоа?

Ну посмотри его код. Ты видемо этого никогда не делал? Там сплошные макросы. Короче велосипед велосипеда.

умел больше и делал это лучше

/0

man unixway

Да, я намекаю на «Делать одну вещь, но делать её хорошо».

современных стандартов качества

Агент майкрософт, уйди. Стандарты в GNU/Linux, к вашему сведению, сударь, никто не устанавливает, каждый делает что ему хочется. Но Леннарт решил выпендрится со своей поделкой и пропиарила его красношляпа, только из-за этого его systemd начали использовать везде. Не будь красношапки, никто бы даже не посмотрел на это.

В то время как sysvinit делал *фэйлы* на пустом месте (неправильные запуски демонов, в зависимости от состояния-и-окружения текущего сеанса root-пользователя, который делает вызовы запусков)..

Пруфы?

..в systemd вдруг маленькая ошибочка (ни на что не влияющая, в целом)

А где новости про ошибки в SysVInit за последние лет 5? Ой, нету? Ну извините, нужно же чтобы ошибки обязательно были! Ой, мы запилим своё!

альте

Ты таки не поверишь, но в Альте до сих пор и SysVInit пользуются :) И всё работает, свистит, пердит.

Ну посмотри его код. Ты видемо этого никогда не делал? Там сплошные макросы. Короче велосипед велосипеда.

Попрошу конкретный пример. Я его код видел. Уверен, что и Шаповалов его код видел, ибо он контрибьютил туды. Но *сплошных* макросов я там не видел. Есть некоторое количество макросов, упрощающих работу. Но в большинстве своём всё завязано на процедурах.

Макросы сами по себе неплохи. Их просто можно плохо использовать. И такие примеры есть и в системде. Например, streq раскрывается в strcmp == 0, что неплохо. strneq раскрывается в strncmp == 0, что тоже логично, но лично меня поначалу запутало, ибо strneq я с первого взгляда раскрыл как «string not equals», а не «equal n chars of string»

Иными словами, ты понятия не имеешь, какой там код. Понятненько.

Там код с магическими костантами, захардкоженными там и сям литералами, макросами, чисто принципиально - строчными буквами, копипастой кода, плюющий на все конвенции именования переменных: i вполне может быть параметром для instance, b будет длиной чего-то, а не указателем на buf – причем, ладно бы в трехстрочнике и «рядом», но нет — там вполне может быть:

void do_something_with_unit(const char *i, const char *f)

Ну или вот оригинал:

s = new(char, a + 1 + b + strlen(e) + 1); 

  
strcpy(stpcpy(stpcpy(stpcpy(mempcpy(t, p, fn - p), ".#"), extra), fn), "XXXXXX"); 

if (path_is_absolute(option+15))

А уж проверок там понатыкано –– иногда некоторые вещи проверяются как минимум три раза подряд (есть подозрение, что чисто из-за абсолютной бессистемности проверок), причем эта информация частенько никак не используется. Т.е. может вначале проверятся кусок строки на валидность (при этом выясняется длина и наличие какого-нибудь @ или постфикса), потом часть этих действий повторяется в нормальном коде.
Да ладно уж, чего стоит один их собственный парсер-лисапед конфигов с треугольными колесами — напуркуа он там, кроме как из-за NIH и чтобы «примешивать» его код где можно и нельзя, не пойму. И работает он, как и любой «наивный» ручной парсер, не шибко быстро — системкомбайн спасает лишь то, что язык конфигов прост, сами конфиги далеко не в мегабайтовых объемах идут, ну и мощность современных железок тоже сказывается.

Так что не надо тут заливать про «отличный код».

void do_something_with_unit(const char *i, const char *f)

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

s = new(char, a + 1 + b + strlen(e) + 1);

Не нашёл. Можно ссылку?

strcpy(stpcpy(stpcpy(stpcpy(mempcpy(t, p, fn - p), ".#"), extra), fn), «XXXXXX»);

Нашёл. Это эпично :))

c другой стороны, даже этот эпичный кусок достаточно комментирован, чтобы понять, что он делает, если знать, что делают mempcpy и stpcpy. Покажи, как написал бы ты этот участок?

if (path_is_absolute(option+15))

Тоже нашёл. Выглядит, конечно, так себе, но двумя строчками выше там

} else if (startswith(option, "tcrypt-keyfile=")) {

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

Аргументация с моей стороны предельно простая: потому что так удобнее.

ох ты ж биомать.

«Под рутом работать удобнее.»

«Иксы в ядро удобнее.»

«Забить на архитектуру и совместимость удобнее.»

Удобнее != надёжней.

Plain text лучше восстанавливаются, как ни странно. Их можно хотя-бы частично восстановить. А бинарный даже не прочитается, если в нём изменить несколько байт. Источник: По личному опыту.

А когда ты видел повреждения ФС, приводящие к потере «нескольких байт»?

А бинарник systemd теперь разделён на systemd, systemd-nspawn, systemd-crond, systemd-logind, etc.? Или это всё те же ссылки на один бинарник?

Ололо, это никогда не было «ссылками на один бинарник».

А рут то не смонтировался =) Ну бизибоксовский выполнится, если повезёт.

Позволь спросить, а откуда запускается systemd, если корневая ФС не смонтировалась?

Но вот с SysVInit у меня такого никогда не было, а как падал systemd вместе с ядром я видел лично.

Потому что sysvinit похер на ошибки, он будет продолжать «запускаться», даже если каждый вызов будет заканчиваться SIGBUS'ом.

Ну посмотри его код. Ты видемо этого никогда не делал? Там сплошные макросы. Короче велосипед велосипеда.

Я туда контрибьютил. Да, там в ряде мест используются макросы, и это скорее хорошо — под них получается спрятать часть бойлерплейта. Не понятна связь между «макросы» и «велосипед».

/0
man unixway
Да, я намекаю на «Делать одну вещь, но делать её хорошо».

Юникс-вей не нужен.

А где новости про ошибки в SysVInit за последние лет 5? Ой, нету? Ну извините, нужно же чтобы ошибки обязательно были! Ой, мы запилим своё!

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

Молодцы, пусть возьмут с полки пирожок. Сказать-то что хотел?

один их собственный парсер-лисапед конфигов с треугольными колесами

С каких это пор gperf считается собственным парсером-лисапедом?

void do_something_with_unit(const char *i, const char *f)

Такого там точно нет.

s = new(char, a + 1 + b + strlen(e) + 1);

...где a, b и e — куски строки после парсинга, которые никак по-другому и не назовёшь.

strcpy(stpcpy(stpcpy(stpcpy(mempcpy(t, p, fn - p), ".#"), extra), fn), «XXXXXX»);

А здесь-то что не так? Это последовательность конкатенаций, записанная в одну строчку для удобства.

Я бы здесь, скорее всего, использовал snprintf() с ключами %.*s, но это дело вкуса.

if (path_is_absolute(option+15))

...которое идёт сразу после строкового литерала, так что всё понятно.

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

Месье, наверное, не в курсе, что сначала нужно проверить все входные данные, а потом уже с ними работать?

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

https://github.com/systemd/systemd/blob/master/src/basic/unit-name.c#L457 Только не надо про то, что i == instance ясно уже из имени функции. Там, «по соседству» есть:

int unit_name_to_instance(const char *n, char **instance) {
        const char *p, *d;
        char *i;

Ну и вообще. Нелюблю я читать однобуквенные переменные (разве что за исключением временных, где все «рядом и на виду», счетчиков и прочей «классики»). Те же трех-четырехбуквенные «buf, inst, pad» позволяют имхо намного быстрее «въехать» в код.

Не нашёл. Можно ссылку?

не помню, где надыбал. Держи замену:

https://github.com/systemd/systemd/blob/646853bdd8b1337204643aa014ff3f1f49d91...

 t = new(char, strlen(p) + 2 + strlen(extra) + 6 + 1);
        if (!t)
                return -ENOMEM;

        strcpy(stpcpy(stpcpy(stpcpy(mempcpy(t, p, fn - p), ".#"), extra), fn), "XXXXXX");

или https://github.com/systemd/systemd/blob/26ccc1d0875b0e0c4306b03a52aff712c23d4...

     ret = new(char, (e + 1 - path) + k + 1);
        if (!ret)
                return NULL;

Покажи, как написал бы ты этот участок?

А вообще, интересный подход с вопросом «сделай лучше» =). Дело в том, что у меня как минимум бы не было литерала. Ну и сам подход был бы другим.
Наваял бы, как минимум, в отдельную функцию. Благо нужно (и используется, частью копипастой) такое клепание и соединение довольно часто. Ну и можно заодно разбить на отдельные шаги, благо на скорость это никак не влияет, а читаемость всяко будет выше, плюс приятней при дебаге.

так что из контекста понятно.

Это да, но тут все дело в том, что если позже придется что-то менять-переписывать, то задолбаешься отлавливать и править все эти +15+2+6+1, раскиданные по всему коду.

Юникс-вей не нужен

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

Только не надо про то, что i == instance ясно уже из имени функции. Там, «по соседству» есть:
int unit_name_to_instance(const char *n, char **instance)

А тут понятно, что n==name из имени :)

Ну и вообще. Нелюблю я читать однобуквенные переменные (разве что за исключением временных, где все «рядом и на виду», счетчиков и прочей «классики»). Те же трех-четырехбуквенные «buf, inst, pad» позволяют имхо намного быстрее «въехать» в код.

Имхо, вкусовщина. Я, например, после вкуривания системдешного кода стал писать «r» вместо «ret», и мне стало как-то удобнее. Но если у кого-то проблемы с таким стилем — бить себя в грудь и навязывать не стану.

Держи замену:

Ну, тут то же самое, что и в предыдущем: смысл логических констант видно по литералам ниже.

А вообще, интересный подход с вопросом «сделай лучше» =).

Не, это не подход «сделай лучше». Мне действительно интересно, какую альтернативу ты бы предложил. Лично я изначально видел альтернативой расписать каждый вызов функции отдельно. Но это громоздко, поэтому тут и ужато всё в одну строку. А вообще, наверное, было бы лучше сделать так, как intelfx предложил — через sprintf.

Это да, но тут все дело в том, что если позже придется что-то менять-переписывать, то задолбаешься отлавливать и править все эти +15+2+6+1, раскиданные по всему коду.

Ну, не по всему коду, а в одной функции. Но да, тут нужно быть аккуратным.

Такого там точно нет.

А если найду? https://github.com/systemd/systemd/blob/master/src/basic/unit-name.c

...где a, b и e — куски строки после парсинга, которые никак по-другому и не назовёшь.

Ага, ага. Вместо е писать ext(ension) не позволяет религия.

Месье, наверное, не в курсе, что сначала нужно проверить все входные данные, а потом уже с ними работать?

Мусью прочел только про «понатыканно»? Во первых, проверяя три раза подряд (тот же unit_name_is_valid проверяется в самой https://github.com/systemd/systemd/blob/master/src/basic/unit-name.c#L162 как и перед ее вызовом) ничего нового не узнаешь. Во-вторых - «понатыканно» как раз про бессистемность проверок. Где-то что-то три раза, где-то, как показывает новость, ни одного.

С каких это пор gperf считается собственным парсером-лисапедом?

С каких это пор gperf можно парсить o_O Ну и сам в соседнем комменте про парсинг же писал.