Выпуск Systemd 243 с устранением уязвимостей

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

Простой демон я там выше привёл - вперёд, продемонстрируйте вашу элементарную обёртку на shell! Посрамите интеллектуальное большинство!

strace/wait

wait не сработает для не дочернего процесса.

strace - вы ещё под gdb в продакшн запускать предложите.

Да. Всё равно придётся править скрипт

Я вызовы nsenter немаленькой простынёй не считаю. Какие-то обновления касаемо nsenter? Вы что-то в какие-то дебри лезете.

Ох, разгребать потом после таких вот любителей строить из палок и изоленты...

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

А служба — это общая концепция.

Эта «общая концепция» прямиком из венды.

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

Теперь модно делать велосипеды в виде «скрипта, запускающегося на каждую новую строчку из кольцевого буфера сообщений ядра» ? А что будет с системой при шторме из битых UDP пакетов, например? Так-то нормальный человек напишет что-то типа kern.* |/some_fifo и повесит демона слушать этот fifo, чтобы не запускать процесс на каждый чих.

Ну я тоже так считаю. А @crypt говорит, что-де systemd только к версии 243 дошёл до того, что все остальные якобы всегда умели и делали.

Ты не понял. Раньше такой проблемы вообще не существовало. А вот системдэ её создал и героически решал аж до версии 243.

Надо написать просто этот самый враппер с дальнейшим prctl и reparenting'ом, например.

Какие-то обновления касаемо nsenter?

Обновления init-скрипта в следующей версии пакета.

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

А на каком языке написан shell и большинство вызываемых утилит, не напомните?

Обновления init-скрипта в следующей версии пакета.

Чем одно отличается от другого?

А на каком языке написан shell и большинство вызываемых утилит, не напомните?

В теории на C, написать же их вы можете сами на чём угодно. Ах, да, они же гораздо меньше и потому поддерживать их гораздо легче. И писали их не поттеринги, закрывающие тикеты безопасности с WONTFIX.

Надо написать просто этот самый враппер с дальнейшим prctl и reparenting'ом, например.

Ага. Простой и понятный init-скрипт на марше.

Не сработает, кстати. Не переживёт первый же fork().

Ну так подстрой, Столлман дал тебе свободу, а ты ей пользоваться не хочешь!

А я ничего против гуя и не имею лол.

Простой демон я там выше привёл - вперёд, продемонстрируйте вашу элементарную обёртку на shell! Посрамите интеллектуальное большинство!

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

Ну объясни, почему prctl с PR_SET_CHILD_SUBREAPER не сработает.

а ты ей пользоваться не хочешь!

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

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

+

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

Умеет запускаться и падать. Это же демонстрационный пример.

умеет ли он в foreground

Дошло наконец?

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

Бгг. Завидую твоей вере в окружающих.

Ну объясни, почему prctl с PR_SET_CHILD_SUBREAPER не сработает.

man 2 prctl:

...

PR_SET_CHILD_SUBREAPER (since Linux 3.4)

    ...The setting of this bit is not inherited by children created by fork(2) and clone(2). The setting is preserved across execve(2).

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

Я подозреваю, что fork'и и clone'ы оригинального процесса не будут иметь subreaper, а всё остальное будет. И его форки с дочерними процессами будут учтены.

Всё очень просто, для этого нужно хоть раз осилить документацию к systemd, а люди привыкли к старому, учиться новому не хотят. Банальная лень и ЧСВ, ничего особенного. Нормальный админ/инженер просто потратил бы вечер на вдумчивое чтение доков и овладел бы актуальным инструментом, который используется в подавляющем большинстве решений, в то время как нытики продолжают рассказывать на форумах, какая системда говно и как страшно жить. Жалко таких людей, но они сами себя закапывают в дебри околорелигиозной ноофобии.

Это модель отношений: корпорации для терпил, а не сообщество для сообщества. Следовать вашему рецепту - это значит признать, что линукс превратили в виндовс2 ... ну с некоторыми особенностями - типа открытость кодов ... но изменить ничего нельзя, выбрать ничего нельзя - можно только адаптирваться к насунутому корпорациями «инструменту». Больше нет «я хочу пользоваться этим инструментом вот так», а есть «приказала МС ... ой, простите, РХ - сиди изучай и помалкивай в тряпочку».

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

Thunderbird отдали «сообществу» и там меняется только версия движка, никакого развития.

Да, посмотрел в ядре, и похоже, что вы правы. Интересно, что этот флаг добавил... Леннарт Поттеринг! :)

А можно было жить в foreground и не мучаться.

А можно было жить в foreground и не мучаться.

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

Можно, конечно, сдуть пыль со старых Ubunt-овских костылей для upstart (expect stop) - но хотелось бы чего-нибудь менее уродского. :)

Ты путаешь бритву Оккама с бритвой Хэнлона.

Ну например переписываешь ты gdm так, чтобы он использовал logind вместо consolekit, а logind в свою очередь делаешь неотделимым (трудноотделимым) от systemd. И готово дело.

А к gdm можно еще кучку пакетов прибить зависимостями или еще как.

...и в продакшн! Ох, разгребать потом после таких вот любителей строить из палок и изоленты...

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

Когда уже в репах арчика-то? А то новость запостили, а обновы всё нет.

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

Что он может, чего не может дефолтный в моем дистре OpenRC? Есть смысл менять, если все работает? Спрашиваю на полном серьезе. Все же, systemd сейчас очень популярен.

https://youtu.be/a27YCMFsob0 вот, благотворно действует на неокрепший мозг менеджера.

Что он может, чего не может дефолтный в моем дистре OpenRC?

Он тебя может сделать одмином-системд! Это ну ооочень востребованная профессия, в будущем, ага...

Так не используйте gdm.

Я вообще не вижу проблемы. Повторю - старое никто не отбирал, вон оно лежит. Берете тот же дебиан до системд и форкаете его в девуан, что и было сделано. И далее - разрабатывайте, развивайте, используйте, пересобирайте прибитые пакеты.

Если инструмент востребован, то его будут использовать и развивать и люди найдутся для этого. Но пока я вижу, что девуан тот особо никому не нужен, а в 90% дистрибутивов системд.

пока я вижу, что девуан тот особо никому не нужен

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

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

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

Но пока я вижу, что девуан тот особо никому не нужен,

На нем базируются heads и maemo leste. Тобишь еще служит основой для других.

а в 90% дистрибутивов системд.

Не 90%, а 95%. И все они клоны красношапки.

Умеет запускаться и падать. Это же демонстрационный пример.

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

Дошло наконец?

Дошло что? Если умеет - то способ решения один, если не умеет, то другой, если сохраняет pid - то можно попроще, если нет, то чуть сложнее. А может оно вообще само всё в логи пишет и никаких врапперов вообще не нужно. Можно, конечно, написать и универсальное решение из всяких pgrep, prctl и даже strace в совсем долбанутых случаях, но нахрена это делать, если в каждом конкретном случае можно обойтись гораздо меньшим?

Опять же, вот что мешает просто добавить нужное логгирование в демона?

Не, я конечно понимаю, что может найтись какое-то проприетарное поделие, которое непрерывно форкается по 10 раз в секунду и меняет cmdline и даже environ на набор случайных символов, не пишет никаких логов и pid-файлов, но зачем такое говнище вообще использовать?

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

Собственно, суть.

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

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

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

Теоретик? Посмотрю я, как вы будете объяснять, что вся контора работать ну никак не может, поскольку «демон упал - а вдруг там уязвимость?»...

Опять же, вот что мешает просто добавить нужное логгирование в демона?

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

(А конкретный демон, с которым возникла такая задача, раньше им не был, но потом его отделили в backend, и хотя работает он более-менее нормально, в нём осталось немало старых кусков кода, выплёвывающих что-то типа «Invalid pivot data» и делающих exit() с кодом из enum. Переписывать это никто не будет. Увы, мир не идеален.)

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

Щито? Способ разобраться в причинах падения - это логи и дебаггер. Код возврата - оно совсем для другого. :)

Теоретик?

Практик, уже десятки лет как.

Посмотрю я, как вы будете объяснять,

Объяснять кому? Самому себе?

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

А это повод для жёстких мер по отношению к тому дебилу, который жестко завязал всю работу конторы на какого-то криво написанного проприетарного демона не оставив никакого failover'а.

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

Способ разобраться в причинах падения - это логи и дебаггер

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

Объяснять кому? Самому себе?

Вы работаете один и на себя?

А это повод для жёстких мер по отношению к тому дебилу, который жестко завязал всю работу конторы на какого-то криво написанного проприетарного демона не оставив никакого failover'а.

Я вот таких ситуаций не допускаю, например. Контора должна быть способна продолжать работу даже если что-то внезапно сломалось, упало или перестало работать

Демон написан моими коллегами. Как и в любом ПО, в нём бывают ошибки. Резерв невозможен в силу специфики его работы (пришлось бы городить синхронизацию состояния).

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

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

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

Демон написан моими коллегами.

раз

Как и в любом ПО, в нём бывают ошибки.

два

Резерв невозможен в силу специфики его работы

три

Вы как будто в своём выдуманном мирке живёте

четыре

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

Опять же, вот что мешает просто добавить нужное логгирование в демона?

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

пришлось бы городить синхронизацию состояния

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

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

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

Вы работаете один и на себя?

Я совладелец конторы. Так что работаю не один и не только на себя.

Демон написан моими коллегами. Как и в любом ПО, в нём бывают ошибки. Резерв невозможен в силу специфики его работы (пришлось бы городить синхронизацию состояния).

Архитектора - на рею.

Вы как будто в своём выдуманном мирке живёте

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

но и с малоизвестными

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

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

Если избыточность обеспечить невозможно, то нехрен завязывать на такой сервис весь workflow.

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

времена меняются, а этот мелкий недопровайдер по-прежнему не может понять, что Restart=on-failure - опциональная не дефолтная настройка. Ему она не нужна, а например мейнтейнерам docker в дебиане - нужна. Бывает же.

Посмотрю я, как вы будете объяснять, что вся контора работать ну никак не может, поскольку демон упал

уха-ха !

давным давно админил я одну контору....

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

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

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

звался этот говнодемон wingate и работало это энтерпрайзненькое решение под божественным 2000-ным сервером...

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

ЗЫ:

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

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

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

системдфанбой, что ты делаешь на этом сайте? тебе на сайт микрософта, пока мамка не заметила :)

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

/facepalm

Код выхода - это один из способов передать информацию. Всё остальное - лишь ваши домыслы.

Я совладелец конторы.

Ну вот и выходит, что предъявить вам некому.

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

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

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

Если избыточность обеспечить невозможно, то нехрен завязывать на такой сервис весь workflow.

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

Падение очень часто означает наличие уязвимости, соответственно использовать такой демон категорически нельзя

Значит, наряду с PostgreSQL надо поднять и продублировать всё в MySQL, ejabberd дополнить каким-нибудь openfire, локальный gitlab подпереть... чем, кстати?

Надеюсь, в вашей правильной конторе всё именно так и устроено.

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

И при этом процентов так 90 посетителей этого сайта узнали в этом описании свою контору. :)

Внезапно, преимущества такого ПО как система инициализации и проявляются тогда, когда всё работает неидеально.

сейчас уже столько средств и хранилищ на любой вкус для совместной работы с данными

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

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