systemd local DoS

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

OK. Нашёл две таких функции. Это всё?

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

Знаешь что я тебе скажу? Плохой код — это не тот, где переменные названы не так, как ты бы хотел. Это когда нет проверок на ошибки и OOM, когда нет диагностической распечатки, когда код не побит на функции и так далее.

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

Вообще-то проверку входных данных принято делать перед каждым явным использованием, даже если это означает повторение кода. Странно, что мне приходится разъяснять такие основы.

где-то, как показывает новость, ни одного

Забытая проверка != отсутствие проверок. И да, сугубо для протокола: в сабжевом месте написали assert вместо возврата кода ошибки.

Не прикидывайся шлангом.

OK. Нашёл две таких функции. Это всё?

Попробуй глазами. Там их больше. Ну и заодно и остальной код глянь. https://github.com/systemd/systemd/blob/master/src/basic/env-util.c

static int env_append(char **r, char ***k, char **a) {
har **strv_env_delete(char **x, unsigned n_lists, ...) {
char **strv_env_unset(char **l, const char *p) {
char **strv_env_set(char **x, const char *p) {
[/CODDE]
Это я первое попавшееся открыл.
[quote] Знаешь что я тебе скажу? Плохой код — это не тот, где переменные названы не так, как ты бы хотел. [br][/quote]Знаешь, что я тебе скажу? Плохой код начинается с наплевания на общепринятые практики. 

[quote] Это когда нет проверок на ошибки и OOM,[br][/quote]Проверки на ООМ тепер оказывается что-то особенное o_O

[quote] Вообще-то проверку входных данных принято делать перед каждым явным использованием, даже если это означает повторение кода. Странно, что мне приходится разъяснять такие основы.[br][/quote]Не прикидывайся и не юли, основы тут ни при чем. Претензии к качеству проверок и несогласованности, кто проверяет данные - иногда вызывающая сторона, частенько обе. Проверки пересекаются и вообще делается куча лишних телодвижений. Зачем тогда было вообще писать на Си ...
[quote] Не прикидывайся шлангом.[br][/quote]Т.е.ты не знаешь, что такое парсинг? Ну окай.

OK. Нашёл две таких функции. Это всё?

Попробуй глазами. Там их больше. Ну и заодно и остальной код глянь. https://github.com/systemd/systemd/blob/master/src/basic/env-util.c

static int env_append(char **r, char ***k, char **a) {
har **strv_env_delete(char **x, unsigned n_lists, ...) {
char **strv_env_unset(char **l, const char *p) {
char **strv_env_set(char **x, const char *p) {

Это я первое попавшееся открыл.

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

Знаешь, что я тебе скажу? Плохой код начинается с наплевания на общепринятые практики.

Это когда нет проверок на ошибки и OOM,

Проверки на ООМ тепер оказывается что-то особенное o_O

Вообще-то проверку входных данных принято делать перед каждым явным использованием, даже если это означает повторение кода. Странно, что мне приходится разъяснять такие основы.

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

Не прикидывайся шлангом.

Т.е.ты не знаешь, что такое парсинг? Ну окай.

Не будь красношапки, никто бы и на Линюкс не посмотрел.

Ну вот представь, ты настроил всё по-умному, запускаешь недоверенный софт типа браузера или скайпа от отдельных пользователей, настроил selinux и сидишь довольный. А тут бац и уязвимость в браузере/skype/ты сам скачал вредоносный код и запустил - и получаем зависание. Это явно некорректная ситуация.

Или, например, имеем shared hosting с SSH доступом или VPS на базе контейнеров - и получаем, что один пользователь может положить сайты всех остальных. Это тоже совсем не круто, ибо мало ли какие убытки могут поиметь другие клиенты за время простоя.

Или, например, имеем shared hosting с SSH доступом или VPS на базе контейнеров - и получаем, что один пользователь может положить сайты всех остальных. Это тоже совсем не круто, ибо мало ли какие убытки могут поиметь другие клиенты за время простоя.

Да не работает оно в контейнерах, узбагойтесь.

Патч уже есть?

Хотя срач читать всё интереснее. :)

Проверил, не заработало. Версия 215.

По поводу критики systemd — да, не юниксвейно. Но ведь и ядро от финского студента по сравнению с микроядрами — такое же отступление от юниксвея. Man Tannenbaum vs Torvalds.

Мне всё равно, что штука — большой кухонный комбайн со встроенным пылесосом и насадкой-фаллоимитатором. Всё равно, что логи бинарные. Когда обзавелся systemd вместе со свежеустановленным Debian, система стала мгновенно загружаться и столь же резво выключаться.

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

Да что вы говорите? Тот-то вас каждый раз кастуют в темы ненуднод. Это видимо по причине того насколько он удобен. И то не раз было завершением «ну да это бага в N версии»... или «это не предусмотрено ненужнод» «обойти таким костылем» Ну не надо только тут рассказывать про «им банально удобнее пользоваться».
ЗЫ «кучка разрозненных тулз, скреплённых соплями и шеллом» описанное в топике не вызывает. Вам нужно работать или «модно молодежно»? Я выбираю первый вариант.
ЗЫЫ Я реально пытаюсь быть объективным, но ненужнод для прода все еще не готов.

ненужнод для прода все еще не готов

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

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

[x]inetd Это что по вашему?

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

Клево, че. Давайте крон в инит забубеним. Вот только вопрос, Зачем?

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

Примеры в студию плиз.

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

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

Повреждённый *.journal-файл не менее читаем, чем повреждённый *.log-файл.

BTW, почему любители текстовых логов не возмущаются от того факта, что в любом реальном продакшене все логи хранятся в полноценной БД? :)

BTW, почему любители текстовых логов не возмущаются от того факта, что в любом реальном продакшене все логи хранятся в полноценной БД? :)

Это вы про офтопик? А мы вообще-то как минимум про хост систему.

в любом реальном продакшене все логи хранятся в полноценной БД

Как то в syslog всю жизнь логи сетевые складывали и ничего так, все живы.

Повреждённый *.journal-файл не менее читаем, чем повреждённый *.log-файл.

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

Зачем? Хотя это риторический вопрос, потому что все поголовно кукакритики сустемд не разбираются в вопросе от слова «никак».

strings /var/log/journal/`cat /etc/machine-id`/user-1000.journal|grep '^MESSAGE='|cut -d'=' -f2-

[x]inetd Это что по вашему?

Это, как минимум, не sysvinit.

Клево, че. Давайте крон в инит забубеним. Вот только вопрос, Зачем?

Для удобства.

Примеры в студию плиз.

Пример всё тот же: полностью надёжный supervisor на контрольных группах, развитый механизм зависимостей.

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

«нытики» оценили качество «современных стандартов качества» в топике.

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

Примеры в студию. Да и еще bsd плиз не забудьте.

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

«Такая маленькая птичка, а так нагадила», ну да «маленькая ошибочка» которая кладет всю систему, «ничего ничего, все нормально, она же маленькая»

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

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

полностью надёжный

Абсолютная надежность? Да вам, товарищ, надо бы галоперидольчика.

# ls /var/log/journal/
ls: cannot access /var/log/journal/: No such file or directory

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

Интересно, что ты забыл на техническом форуме?

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

«Полностью надёжный» — это термин. Имеется в виду, что процесс не может выйти из-под контроля супервизора, просто сделав пару лишних форков или setsid.

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

Ну нет у меня там их, просто нет. centos7

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

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

«Полностью надёжный» — это термин.

И откуда ты взял этот термин?

Да еще и чтобы он значил

что процесс не может выйти из-под контроля супервизора, просто сделав пару лишних форков или setsid.

Так чего ты тогда ноешь-то? Там у тебя наверняка включён форвардинг в rsyslog по умолчанию.

Ставил систему по дэфолту, так должно быть? Если да, то снимаю вопрос про бинарные логи (был не прав погорячился, обещаю исправиться, не везде они под ненужнод бинарные).

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

Разницу видим? Если скрипт админ и сам может поправить, то писанину на C крайне редко.

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

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

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

Так никто и не говорит.

И откуда ты взял этот термин?

Коряво перевёл «fully reliable».

Да еще и чтобы он значил

что процесс не может выйти из-под контроля супервизора, просто сделав пару лишних форков или setsid.

Ну вот как сказать... Рассмотрим, например, sysvinit (без ничего). В нём тоже есть зачаточный супервизор в виде директивы respawn. Но он ненадёжен: процесс может сделать форк и выйти из-под контроля. Т. е. нужна кооперация со стороны того, что мы запускаем. systemd не имеет такого недостатка.

Какой вопрос, такой и ответ. systemd тоже «делает одну вещь и делает её хорошо»: запускает, группирует и отслеживает процессы.

Верно, не могу не согласиться. Стоимость правки бага в systemd сильно выше, чем в скриптоте.

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

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

Рассмотрим, например, sysvinit (без ничего).

без ничего

Это бессмысленное рассмотрение.

В качестве синтетического примера — вполне осмысленное.

В качестве синтетического примера — вполне осмысленное.

Я так не считаю, потому что такая постановка задачи заведомо ведет к результату, который не будет связан с реальностью. Плохая модель -> никудышные результаты.

Система инициализации в стиле SysVinit так или иначе следует идеологии простоты. Если нужны усложнения, то эти усложнения должны быть отдельными сущностями [1]. Таким образом мы получаем здоровую экосистему взаимозаменяемых элементов. Поэтому рассмотрение отдельного этой экосистемы — верный путь к пустой трате времени.

[1] Это, возможно, стоит раскрыть шире. С позиции информационной безопасности в том случае, если пользователь (в широком смысле этого слова) не нуждается в некоторой функциональности, то в идеале этой функциональности быть не должно.

конаническая

Вся суть поклонников системд в одном слове.

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

Полностью согласен. И добавлю, а вот точно должно ли быть 15, 2, 6, 1?
Мне вспомнился один давний проект, в котором коллега +N накопипастил во многих местах, выяснилось это по прошествии лет при рефакторинги, на вопрос «какого юха» и почему именно N а не M он конечно ответить уже не смог. Число по всей логике не упиралось никуда.

Вообще-то проверку входных данных принято делать перед каждым явным использованием, даже если это означает повторение кода. Странно, что мне приходится разъяснять такие основы.

Вы и правы и нет. Для варианта написанного на C работающего в pid 1 нужна согласованность кода, а не повторение проверок.

Когда обзавелся systemd вместе со свежеустановленным Debian, система стала мгновенно загружаться и столь же резво выключаться.
и столь же резво выключаться.

Звучит двусмысленно на уровне серверов :)

Что такое «согласованность кода» и как она нарушается?

Я повторяю вопрос в пятый раз за тред: опиши правильную, на твой взгляд, архитектуру (детально) и опиши, от чего конкретно она защищает.

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

Не надо делать 100500 повторных проверок. Это замедляет выполнение.

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

Если мамонт упадет, это услышат многие....

Видимо, ты просто не знаком с такой штукой, как поверхность атаки (attack surface).

Кидаться общими словами все горазды.

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