форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Локальная DoS-уязвимость в systemd"	+/–
Сообщение от opennews (??) on 29-Сен-16, 21:02
В системном менеджере systemd выявлена (http://www.openwall.com/lists/oss-security/2016/09/28/9) локальная уязвимость. При поступлении сообщения нулевой длины в сокет уведомлений systemd, PID 1 зависает на системном вызове pause, после чего невозможно запустить/остановить демоны или выполнить "чистую" перезагрузку, а systemd-сервисы в стиле inetd перестают принимать соединения. Так как сокет уведомлений /run/systemd/notify доступен всем на запись, то любые локальные пользователи могут вызвать отказ в обслуживании на системах с systemd. Уязвимость проявляется во всех версиях systemd, начиная по крайней мере с версии 209. Атака сводится к выполнению команды    NOTIFY_SOCKET=/run/systemd/notify systemd-notify "" URL: http://www.openwall.com/lists/oss-security/2016/09/28/9 Новость: http://www.opennet.me/opennews/art.shtml?num=45244
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

5. "Локальная DoS-уязвимость в systemd"	+/–
Сообщение от Аноним (??) on 29-Сен-16, 21:33
нечему удивляться, хочешь миришься с этим, либо сидишь на дистре без сабжа. Или вон бсд подтянется 5го октября, правда там тоже не лучше и launchd притащат начнется тоже самое.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от АнонимХ (ok) on 29-Сен-16, 21:49
	> launchd есть надежда, что оно будет академично по-бздешному продуманней, чем сабж. Например, pkg-ng, довольно хорош у них получился
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	23. "Локальная DoS-уязвимость в systemd"	–5 +/–
	Сообщение от . on 29-Сен-16, 23:43
	pkg-ng научился в человеческое разруливание циклических зависимостей? Может он хотя бы умеет различать release/version/serial? Поддерживает provides/requires/conflicts? Умеет в {pre,post}{{un,}install,update} скрипты? Без всех этих способновлей он пакетным менеджером называться не имеет права.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	34. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 03:54
	pkg info xcb-util xcb-util-0.4.0_1,1 Name           : xcb-util Version        : 0.4.0_1,1 ... Shared Libs required:         libxcb.so.1 Shared Libs provided:         libxcb-util.so.1 https://github.com/freebsd/pkg#pkgfmt Valid scripts are: pre-install post-install install pre-deinstall post-deinstall deinstall pre-upgrade post-upgrade upgrade
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	35. "Локальная DoS-уязвимость в systemd"	–5 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 05:32
	> Version        : 0.4.0_1,1 Версию и билд вижу. Serial (aka семейство) - нет > Shared Libs required: > Shared Libs provided: Это просто великолепно! А бинарники указать можно? А руками? А пакеты? А метапакеты? А надо. > Valid scripts are: Эт да. Проглядел. Ну и я не увидел секции provides/requires/conflicts. Попакетно. С мета-пакетами. Что-то вроде: Name           : apache Version        : 2.2 Requires       : meta/www-filesystem-base Provides       : meta/www-server Confclicts     : www/nginx
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	45. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от тигар (ok) on 30-Сен-16, 08:58
	>Версию и билд вижу. Serial (aka семейство) - нет Расскажите, пожалуйста, что такое "семейство" ? а то может в более других (отличных от привычных) утилитах оно наз-ся по другому как-то... чтобы 2 раза не вставать: а что такое "билд" в строке 0.4.0_1,1 ? > Это просто великолепно! А бинарники указать можно? А руками? А пакеты? А метапакеты? А надо. какие, простите, бинарники? какие, простите, [мета]пакеты? содержимое "потрохов" пакета  (список бинарников, или чего там Вам нужно) можно было получить еще в pkg_tools (в pkg, естественно, тоже). > Что-то вроде: > Name           : > apache > Version        : 2.2 ... > Confclicts     : www/nginx а это где такой интересный мейнтейнер апача есть? и что за кривой пакетный менеджер, в котором даже слово conflicts не смогли правильно написать? или я отвечаю Денису Попову с его уникальным менеджером пакетов сейчас ?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	59. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Аноним (??) on 30-Сен-16, 13:35
	Плакали с такими конфликтами фронты на nginx перед апачем, на одной и той же машине. (Я конечно считаю, что апач не нужен, но не так радикально же)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Аноним (??) on 30-Сен-16, 13:47
	> Версию и билд вижу. Serial (aka семейство) - нет Семейство чего? Гуглить насчет "serial" несколько напряжно. > Это просто великолепно! А бинарники указать можно? А руками? А пакеты? А > метапакеты? А надо. А посмотреть по ссылке? > Ну и я не увидел секции provides/requires/conflicts. Попакетно. С мета-пакетами. deps: {   libiconv: {origin: converters/libiconv, version: 1.13.1_2};   perl: {origin: lang/perl5.12, version: 5.12.4 }; } > Confclicts     : www/nginx А это еще зачем? Что бы независимо от опций сборки и реальной ситуации пакет все равно не ставился?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	62. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 30-Сен-16, 14:35
	>> Версию и билд вижу. Serial (aka семейство) - нет > Семейство чего? Гуглить насчет "serial" несколько напряжно. Скорее часть полной версии, перекрывающая собственно версию исходника. Например, для понижения версии в случае необходимости.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	65. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 16:41
	> Скорее часть полной версии, перекрывающая собственно версию исходника. > Например, для понижения версии в случае необходимости. В следующей строчке: Version        : 0.4.0_1,1 предпоследняя 1 (после _) инкрементируется при перевыпуске той-же версии, последняя 1 (после ,) - при понижении. Фактически, эквивалентно серийнику.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	66. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 16:43
	это он так эпоху в терминах RPM обозвал ?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	67. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 30-Сен-16, 16:49
	> это он так эпоху в терминах RPM обозвал ? Угу, это синонимы.  Рекомендуется s/^Serial:/Epoch:/g (со слов нашего майнтейнера rpm).
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	40. "Локальная DoS-уязвимость в systemd"	–3 +/–
	Сообщение от alp on 30-Сен-16, 08:02
	Если пакетному менеджеру нужно большое количество pre/post и т.д. скриптов, то он просто имеет недостаточный функционал.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	54. "Локальная DoS-уязвимость в systemd"	+2 +/–
	Сообщение от fail on 30-Сен-16, 10:08
	> Если пакетному менеджеру нужно большое количество pre/post и т.д. скриптов, то он > просто имеет недостаточный функционал. как правило - это нужно не пактеному менеджеру, а пакету для выполнения тех или иных служебных работ - добавить/удалить рабочий аккаунт, подготовить/удалить служебное дерево каталогов и т.д.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	56. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от None (??) on 30-Сен-16, 10:31
	Интересно, зачем могут понадобиться циклические зависимости пакетов? По факту, такой набор с циклическими зависимостями - это один пакет, поскольку весь этот набор может быть установлен только сразу весь полностью.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	70. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 20:02
	> довольно хорош у них получился Но пользоваться им нормально все-равно не получится. Потому что монолиты 110 метров заместо пакетов. Хидеры и либы вперемешку. А уж дебагинфо в отдельный пакет отпилить - наверное по меркам BSD это космические технологии.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	80. "Локальная DoS-уязвимость в systemd"	+2 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 21:23
	> Но пользоваться им нормально все-равно не получится. Потому что монолиты 110 метров заместо пакетов. Великий знаток опеннета не в курсе разницы между ракетным менеджером и собственно пакетом? >Хидеры и либы вперемешку. Пакетный менеджер тут то причём? > А уж дебагинфо в отдельный > пакет отпилить - наверное по меркам BSD это космические технологии. А уж знать, о чем с умным видом вещаешь - наверное по меркам опеннетного знатока это что-то запредельное.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	81. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 22:04
	> Великий знаток опеннета не в курсе разницы между ракетным менеджером и собственно пакетом? Хорошая опечатка. > Пакетный менеджер тут то причём? При том что теоретически он есть. Практически толку с этого нет. Наверняка и с launchd будет так же. В bsd все так делают. На бумаге крутейшая системаю. А на серверах - геморроя кусок. > А уж знать, о чем с умным видом вещаешь - наверное по > меркам опеннетного знатока это что-то запредельное. Это слишком хилая попытка троллить. Попробуй еще раз, менее жирно.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	89. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Аноним (??) on 01-Окт-16, 00:36
	> Хорошая опечатка. Бывает. А по теме что-то будет? >> Пакетный менеджер тут то причём? > При том что теоретически он есть. Практически толку с этого нет. Наверняка > и с launchd будет так же. В bsd все так делают. > На бумаге крутейшая системаю. А на серверах - геморроя кусок. Учитывая предыдущие "вумности",  смахивает на очередные размышлизмы анонимого аналитика ) >> А уж знать, о чем с умным видом вещаешь - наверное по >> меркам опеннетного знатока это что-то запредельное. > Это слишком хилая попытка троллить. Попробуй еще раз, менее жирно. Троллить? Отнюдь. Это просто констатация факта, не более. Смотрим внимательно: >> Но пользоваться им нормально все-равно не получится. Потому что монолиты 110 метров заместо пакетов. pkg query %sh xcb-util 55.3KiB % pkg query %sh FreeBSD-ssh 1.58MiB https://packages.debian.org/jessie/linux-image-3.16.0-4-amd64 Installed Size 159,681.0 kB >> Хидеры и либы вперемешку. %  pkg query "%n %c" FreeBSD-ssh FreeBSD-ssh Secure Shell Utilities % pkg rquery "%n %c" FreeBSD-ssh-development FreeBSD-ssh-development Secure Shell Utilities (Development Files) % pkg query "%n %c" FreeBSD-libz           FreeBSD-libz libz package pkg rquery "%n %c" FreeBSD-libz-development FreeBSD-libz-development libz package (Development Files) % pkg search FreeBSD-ssh FreeBSD-ssh-11.0               Secure Shell Utilities FreeBSD-ssh-debug-11.0         Secure Shell Utilities (Debugging Symbols) FreeBSD-ssh-development-11.0   Secure Shell Utilities (Development Files) % pkg search FreeBSD-ssh FreeBSD-ssh-11.0               Secure Shell Utilities FreeBSD-ssh-debug-11.0         Secure Shell Utilities (Debugging Symbols) FreeBSD-ssh-development-11.0   Secure Shell Utilities (Development Files) >> А уж дебагинфо в отдельный пакет отпилить - наверное по меркам BSD это космические технологии. % pkg rquery "%n %c" FreeBSD-libz-debug       FreeBSD-libz-debug libz package (Debugging Symbols) % pkg rquery "%n %c" FreeBSD-ssh-debug FreeBSD-ssh-debug Secure Shell Utilities (Debugging Symbols) Но вам, с высоты мягкой мебели, наверняка виднее )
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	53. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Фунт on 30-Сен-16, 10:00
	А в дистре без сабжа, типа, уязвимостей не бывает?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	57. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Andrey Mitrofanov on 30-Сен-16, 10:50
	> А в дистре без сабжа, типа, уязвимостей не бывает? В /bin/init-е-то? Серьёзно?!
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	63. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 30-Сен-16, 14:39
	>> А в дистре без сабжа, типа, уязвимостей не бывает? > В /bin/init-е-то? Серьёзно?! Кгм, у меня и бинаря-то такого нет -- следовательно, неуязвим. $ rpm -qf --changelog /sbin/init | grep CVE $ _
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	64. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Andrey Mitrofanov on 30-Сен-16, 15:03
	> Кгм, у меня и бинаря-то такого нет -- следовательно, неуязвим. ?) Лучше так: # ps -p 1   PID TTY          TIME CMD # _
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

7. "Локальная DoS-уязвимость в systemd"	+8 +/–
Сообщение от Аноним (??) on 29-Сен-16, 21:53
Говорили им - нечего лезть в иерархии, обязательно что-нибудь пойдет не так, так и случилось.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	46. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Нанобот (ok) on 30-Сен-16, 09:03
	волков бояться - в лес не ходить
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	48. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 09:18
	Тут не про поход в лес, про нырок в канализацию.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

8. "Локальная DoS-уязвимость в systemd"	–2 +/–
Сообщение от Michael Shigorin (ok) on 29-Сен-16, 22:13
А, так вот о чём ldv@ вслух размышлял...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от KM on 29-Сен-16, 23:07
	#32545 - исправлено?
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Michael Shigorin (ok) on 29-Сен-16, 23:45
	> #32545 - исправлено? Не-а.  Вообще говоря, поддержка ветки p7 уже завершена и всё, что в этом плане делается -- сверх обещанного: http://altlinux.org/branches/p7 Но всяко спасибо, что повесили.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	25. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от KM on 29-Сен-16, 23:51
	> Не-а.  Вообще говоря, поддержка ветки p7 уже завершена и всё, что в этом плане делается > -- сверх обещанного: http://altlinux.org/branches/p7 Поэтому я и не выделял ветки, а закинул в общую секцию. > Но всяко спасибо, что повесили. Чем могу.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	31. "Локальная DoS-уязвимость в systemd"	+4 +/–
	Сообщение от Vkni (ok) on 30-Сен-16, 01:38
	> А, так вот о чём ldv@ вслух размышлял... Я надеюсь не при дамах размышлял? Вообще, Михаил, спасибо вам за sysV сборки. Периодически просматривая dev и sisyphus списки рассылки радуюсь, что у меня не systemd.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	73. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 20:17
	> Я надеюсь не при дамах размышлял? Вообще, Михаил, спасибо вам за sysV > сборки. Периодически просматривая dev и sisyphus списки рассылки радуюсь, что у > меня не systemd. Все познается в сравнении. Если так попробовать почитать баги в инит-скриптах - они тоже на все вкусы. Не говоря о том что в sysv вообще нет нотификаций и система просто забьет на сервис повисший при старте. Это вообще никем и никак не обрабатывается.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	77. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Vkni (ok) on 30-Сен-16, 21:00
	Вот тут и познаётся разница между нормальной компонентной системой и кубик-рубик-монолитом. Те инит скрипты, которые я не запускаю, мне не мешают.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	82. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 22:29
	> Вот тут и познаётся разница между нормальной компонентной системой При том большинство компонентов - из бамбука и лиан. И работает характерно, забив на ошибки, продолбав логи и проигнорировав таймауты. Если на таймауты забивать - то и багов в механизме нотификаций не будет. Кто бы сомневался. > и кубик-рубик-монолитом. Из кубик-рубика можно и скрипт позвать, если нужно. С другой стороны кубик-рубик может мне выставить планировщик времени проца и IO и приоритеты, порубить SECCOMP-ом лишние сисколы, выставить лимиты, рестартануть процесс при зависоне и проч. И все это несколькими простыми директивами. Самому это горожить что на скриптах что сишным кодом довольно утомительно, а использовать системы как будто на дворе XX век нравится не всем. > Те инит скрипты, которые я не запускаю, мне не мешают. Те сервисы которые я не запускаю в системд мне тоже не мешают. Более того - сперва я не понимал в чем прикол с 2 levels of disable. А после того как въехал нахожу это удобным и логичным.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	85. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Vkni (ok) on 30-Сен-16, 23:55
	> горожить Ну вот примерно в таком стиле systemd и написан.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	93. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Окт-16, 09:54
	> Из кубик-рубика можно и скрипт позвать, если нужно. С другой стороны кубик-рубик > может мне выставить планировщик времени проца и IO и приоритеты, порубить > SECCOMP-ом лишние сисколы, выставить лимиты, рестартануть процесс при зависоне и проч. > И все это несколькими простыми директивами. В нормальных системах покрутить лимиты-приоритеты может и старый добрый sysvinit, я уже давал Вам ссылку на limited(8): http://git.altlinux.org/gears/s/service.git?p=service.git;a=... > Самому это горожить что на скриптах что сишным кодом довольно утомительно, Да уж, надорваться можно.  Если быть пользователем, а не улучшать используемую ОС. > а использовать системы как будто на дворе XX век нравится не всем. Давайте конкретнее -- "как будто 1995 год": то ли загрузится, то ли зависнет на останове...
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	91. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Окт-16, 09:47
	> Не говоря о том что в sysv вообще нет нотификаций и система просто забьет на сервис > повисший при старте. Это вообще никем и никак не обрабатывается. Если надо, берёте monit и получаете _вменяемый_ мониторинг состояния сервисов.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	106. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Аноним (??) on 06-Ноя-16, 03:52
	> берёте monit и получаете _вменяемый_ мониторинг состояния сервисов. Это чем он более вменяемый реализации в systemd? Тем, что сделан через костыли с опросом списка процессов? Поддержание работоспособности процессов и их перезапуск при падении — задача init'а, причём ещё со времён юниксов. Демоны для наблюдения прописываются в inittab с кейвордом respawn, при их завершении init получает сигнал SIGCHLD от ядра и перезапускает их. Почему вместо развития этой схемы от неё вообще отошли и прикрутили демоны уродливыми костылями через простыни скриптов с утерей возможности наблюдения и перезапуска — непонятно. Systemd с unit'ами — как раз таки исправление этого упущения, возвращение к архитектуре UNIX, а не уход от неё.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	107. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Andrey Mitrofanov on 07-Ноя-16, 14:22
	> Поддержание работоспособности процессов и их перезапуск при падении — задача init'а, > причём ещё со времён юниксов. Демоны для наблюдения прописываются в inittab > с кейвордом respawn, при их завершении init получает сигнал SIGCHLD от > ядра и перезапускает их. Ваши познания уних-вея ввергают нас в ступор благоговения. У не сам ли Леннарт посетил борду! > Почему вместо развития этой схемы от неё вообще отошли и прикрутили демоны > уродливыми костылями через простыни скриптов с утерей возможности наблюдения и перезапуска > — непонятно. Systemd с unit'ами — как раз таки исправление этого > упущения, возвращение к архитектуре UNIX, а не уход от неё. Браво, бис, Леннарт Полиграфович!! Расскажите нам больше, сорвите покровы -- что будет новенького  прогрессивненького в RHEL-9 и s-d v300? Вы ж не просто так после драчки кулочками, и удобные факты под нужный ответ подгоняете -- у Вас же ж вИдение!? Жгите, просим!
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	108. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 07-Ноя-16, 14:34
	>> берёте monit и получаете _вменяемый_ мониторинг состояния сервисов. > Это чем он более вменяемый реализации в systemd? Функциональными тестами. > Поддержание работоспособности процессов и их перезапуск при падении — задача init'а, > причём ещё со времён юниксов. Демоны для наблюдения прописываются в inittab > с кейвордом respawn, при их завершении init получает сигнал SIGCHLD от > ядра и перезапускает их. Если бы Вы ещё сами этой функциональностью пользовались и понимали особенности... я, если что, пользовался -- для N малого особо важных сервисов. Очень вкратце -- да, обычному init не помешала бы возможность прилетевшие сыновнии копытца передать менеджеру вроде того же monit (возможно, поменьше и попроще).  Вот _это_ было бы возвращение и в затронутом Вами аспекте, но никак не неразборный комбайн с невменяемым "незаменимым" апстримом и типично штатовскими методами "продвижения демократии".
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	109. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Аноним (??) on 08-Ноя-16, 22:10
	> Функциональными тестами. Это уже интересно. И как выглядит функциональное тестирование сервиса, допустим, слушающего UART, в терминах monit? Да, он не работает с сетью. Но может быть вполне себе mission critical для моей задачи т.к. должен что-то сделать когда другая железка что-то прислала. И без него система полная тыква и утрачивает смысл существования. В системд - прописываем в конфиг желаемый таймаут и дергаем его апи, он знает что мой сервис живой. А в monit - это как будет выглядеть? Не говоря что проверяющего проверяет ядро и аппаратный вачдог и если и эти проверяющие дадут маху - железный вачдок тикает в железе и когда он дотикает до часа Ч - ну в крайнем случае системе приедет "железный" ресет от вачдога, он безусловный и неоспариваемый. И тут в хитрозадой системной механике вроде все схвачено. А как это делаете вы? Чтобы full coverage всей цепочки? Ну вот например - как проверяется что сам monit не повис? И как взвис обрабатывается? Подперто ли что-то из этого сначала ядерным а потом и аппаратными вачдогами, на случай если софту плохо или даже совсем плохо?
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	110. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 08-Ноя-16, 22:35
	> И как выглядит функциональное тестирование сервиса, допустим, слушающего > UART, в терминах monit? Да, он не работает с сетью. Зависит от того, какие средства внешнего контроля предусматривает сервис.  Например, он может заранее известным образом отзываться на какие USR1/USR2. > В системд - прописываем в конфиг желаемый таймаут и дергаем его апи, > он знает что мой сервис живой. API сервиса? > А в monit - это как будет выглядеть? Если да, то так же. > Ну вот например - как проверяется что сам monit не повис? Там два процесса стартуют -- не помню уже роли и взаимоотношения, но не удивлюсь, если есть и некоторый самоконтроль, чтоб не доводить до hw watchdog, о котором Вы уже и упомянули. > И как взвис обрабатывается? Подперто ли что-то из этого сначала ядерным > а потом и аппаратными вачдогами, на случай если софту плохо или даже совсем плохо? Аппаратным вообще-то подпирается вне зависимости от, на то он и аппаратный. А так у меня monit за всё время эксплуатации -- это где-то с 2003 года, в т.ч. на системах, где почти каждое моргание eth0 звякало в копилку -- не вис ни разу.  В отличие от systemd, который однажды позволил себе упасть в корку в ситуации, когда приличный init продолжил бы работать.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

11. "Локальная DoS-уязвимость в systemd"	+6 +/–
Сообщение от Аноним (??) on 29-Сен-16, 22:58
Это только начало, хехе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Локальная DoS-уязвимость в systemd"	+5 +/–
	Сообщение от freehck (ok) on 29-Сен-16, 23:11
	Естественно. Надо ведь не фичи релизить, а отлаживать существующий функционал. https://pp.vk.me/c637619/v637619910/fabc/5Xg8B3YfD_4.jpg
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Локальная DoS-уязвимость в systemd"	+1 +/–
Сообщение от vitalikp on 29-Сен-16, 23:01
Забавный баг:) Походу нашли случайно. Но для пользователей ничего хорошего, хоть его и исправили, он еще долго может давать о себе знать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от X2asd (ok) on 29-Сен-16, 23:13
	> он еще долго может давать о себе знать. Как?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	18. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от EuPhobos (ok) on 29-Сен-16, 23:20
	Как бамблби наверное, со своим "rm -rf /usr /share...", в айтишных байках.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	22. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от vitalikp on 29-Сен-16, 23:28
	1) Ну в апстриме исправили, а в старых версиях надо еще патч адаптировать. 2) Если на грабли наступили в одном месте и их от туда убрали, то это не значит, что на них нельзя будет через некоторое время наступить в другом.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	37. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Аноним (??) on 30-Сен-16, 06:16
	>Ну в апстриме исправили, а в старых версиях надо еще патч адаптировать   в убунте уже исправили. Вчера вечером команда работала, сегодня утром - уже нет
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	49. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Andrey Mitrofanov on 30-Сен-16, 09:29
	> 2) Если на грабли наступили в одном месте и их от туда > убрали, то это не значит, что на них нельзя будет через > некоторое время наступить в другом. Даже так: Если они входные данные не проверили в одном месте, то такого будет много. Скоро разно-не-цветные шляпы подтянутся, потрясут деревце -- ужо-то будет звездопад.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	78. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Vkni (ok) on 30-Сен-16, 21:03
	> Скоро разно-не-цветные шляпы подтянутся, потрясут деревце -- ужо-то > будет звездопад. Он давно уже идёт - я подписан на ALTовские рассылки, там периодически появляются темы systemD завис/не работает/сломался.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	83. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 22:38
	> Он давно уже идёт - я подписан на ALTовские рассылки, там периодически > появляются темы systemD завис/не работает/сломался. Достаточно посмотреть на опеннете на представителей альтлинукса, чтобы понять как у них системд будет работать. У них и баш-скрипты так же работают, достатчно посмотреть как они баш 3.х таскают. Сметь пофигизма и нежелания разбираться в предмете вообще штука злая.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	87. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Vkni (ok) on 01-Окт-16, 00:01
	> как у них системд будет работать. Без чудес, да. Падает, как у всех остальных.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	94. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Окт-16, 11:11
	>> Он давно уже идёт - я подписан на ALTовские рассылки, там периодически >> появляются темы systemD завис/не работает/сломался. > Достаточно посмотреть на опеннете на представителей альтлинукса, > чтобы понять как у них системд будет работать. Ничего, что здесь обычно отмечаются mike@, cas@, vkni@ -- а вот shaba@, который как раз и является нашим героическим майнтейнером systemd, так сходу не припомню? А от https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&... Ваша обобщалка не распухнет? > У них и баш-скрипты так же работают, достатчно посмотреть как они баш 3.х таскают. http://www.opennet.me/openforum/vsluhforumID3/74697.html#66 > Сметь пофигизма и нежелания разбираться в предмете вообще штука злая. Вы охарактеризовали лишь себя самого, увы.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	74. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 20:22
	> он еще долго может давать о себе знать. Думаю что во всех мало-мальски ориентированных на продакшн дистрах майнтайнеры бэкпортнут фикс и он прилетит ближайшим апдейтом. А кто системы не апдейтит - там и более интересные баги есть, критичный cve в openssl например.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

33. "Локальная DoS-уязвимость в systemd"	+12 +/–
Сообщение от anonymous (??) on 30-Сен-16, 02:58
Говорили же, чем больше всего намешано в PID 1, тем больше пространства для атак и сбоев.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	41. "Локальная DoS-уязвимость в systemd"	–6 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 08:03
	Не ошибается тот, кто ничего не делает.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	50. "Локальная DoS-уязвимость в systemd"	+8 +/–
	Сообщение от Andrey Mitrofanov on 30-Сен-16, 09:30
	> Не ошибается тот, кто ничего не делает. Признаёте s-d ошибкой?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	58. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 11:21
	лол, пилить болгаркой стремянку, на которой стоишь, тоже можно... а потом после ампутации половины конечностей повторять твою фразу... если изначально делаешь глупость, то не ошибиться невозможно.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	71. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от anomymous on 30-Сен-16, 20:15
	Ну да, править кастомно 100500 скриптов от 100500 криворуких мейнтейнеров потому, что они делают что-то не так, как положено - куда лучше.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	75. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 20:25
	> лол, пилить болгаркой стремянку, на которой стоишь, тоже можно... Поэтому фанаты sysv init утверждают что болгарки и стремянки не требуются. Максимум ручная дрель.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	79. "Локальная DoS-уязвимость в systemd"	+2 +/–
	Сообщение от Vkni (ok) on 30-Сен-16, 21:07
	> Поэтому фанаты sysv init утверждают что болгарки и стремянки не требуются. Максимум > ручная дрель. Язык Цэ, на котором написана система systemD - это и есть ручная дрель по сравнению с sysVinit'овским sh'ем.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	84. "Локальная DoS-уязвимость в systemd"	–3 +/–
	Сообщение от Анонми on 30-Сен-16, 22:45
	> Язык Цэ, на котором написана система systemD - это и есть ручная > дрель по сравнению с sysVinit'овским sh'ем. Пока не попробуешь им namespace переключить, попутно расставляя лимиты и переключая планировщики, попутно прописывая лимиты SECCOMP. Вот тут берешь ты sh и ощущаешь себя с ручной дрелью около бетонной стены. А системд - обычный перфоратор среднего пошиба. Да, чинить его сложнее чем ручную дрель. Но и может он намного больше.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	86. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Vkni (ok) on 01-Окт-16, 00:00
	У вас функциональная неграмотность: я писал про языки Цэ и sh, а вы возражаете, рассказывая про системы инициализации.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	92. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от freehck (ok) on 01-Окт-16, 09:47
	Ну и нахрена вам всё это? > namespace переключить Ну и что вам такого дали эти ваши namespace-ы? Улучшенная статистика? О, это да. Статистика - это ведь круто. "Типа контейнеризация, типа безопасность"? Да нет вроде. "Возможность управлять всеми процессами разом"? Блин, ну так для того всегда были pgid и sid у каждого процесса. Вы о них хотя бы слышали, оналитеги хреновы? > расставляя лимиты О да, ulimit-а вам почему-то не хватило. > ... переключая планировщики ... Планировщики по 10 раз на дню переключать. Ага. Зачем?! Кому такое в голову взбрело, что за больное воображение? Кроме вас, системдэ-шников, так *никто* не делает. > ... лимиты SECCOMP ... "Запихнём всё в контейнеры во имя добра"? Как же блин раньше-то люди жили без этих песочниц-то? Пихали процесс в chroot и горя не знали. И то - при крайней необходимости, и только.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	95. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Окт-16, 11:37
	>> расставляя лимиты > О да, ulimit-а вам почему-то не хватило. Он скорее о том, что ulimit из инитскриптов в "обычных дистрибутивах" штатно не дёргается, т.е. придавить получится лишь с точностью до псевдопользователя в тех случаях, когда на них вообще переключаются.  Дистрибутивно решается крайне компактной шелльной библиотекой (ссылка в #93) и точечными добавлениями в собственно пакетах с сервисами.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	96. "Локальная DoS-уязвимость в systemd"	+2 +/–
	Сообщение от freehck (ok) on 01-Окт-16, 17:33
	>>> расставляя лимиты >> О да, ulimit-а вам почему-то не хватило. > Он скорее о том, что ulimit из инитскриптов в "обычных дистрибутивах" штатно > не дёргается Да я, Миш, собственно о том и говорю, что они ставят в заслугу своей любимой поделочке такие вещи, потому что они там есть "из коробки". Но при этом как-то закрываются глаза на то, что: 1) такие штуки можно при желании и к sysvinit приделать, 2) это не делается в "обычных дистрибутивах", потому что в 99% случаев это нафиг не нужно. > т.е. придавить получится лишь с точностью до псевдопользователя в > тех случаях, когда на них вообще переключаются. Ага. И обычно в оставшемся 1% случаев именно так и делается. > Дистрибутивно решается крайне компактной шелльной библиотекой (ссылка в #93) и точечными добавлениями в собственно пакетах с сервисами. Даже не сомневался, что сущесвует. Вообще, у вас там в Альте со скриптами всё хорошо. У вас там Левин есть. Я с ним не знаком, но читал его скрипты, когда gears изучал на досуге. Они клёвые.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	98. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от Vkni (ok) on 01-Окт-16, 18:14
	> Даже не сомневался, что сущесвует. Вообще, у вас там в Альте со > скриптами всё хорошо. У вас там Левин есть. Я с ним > не знаком, но читал его скрипты, когда gears изучал на досуге. > Они клёвые. Реально, если есть проблемы со скриптами, то нужно просто переходить на какой-нибудь более-менее типизированный язык с sh'а. Т.е. вполне можно взять и переписать sysVinit скрипты с sh на тот же Ocaml. Они, конечно, распухнут, но ошибок будет меньше. Хотя, конечно, это явно не идеальный выбор языка - желательно всё-таки написать лёгкую типизированную замену sh. Но архитектура-то всё равно будет не systemDшная (кубик-рубик-монолит), а sysVinit'овская - лёгкое ядро + скриптовая обвязка.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	99. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от freehck (ok) on 01-Окт-16, 19:58
	> Реально, если есть проблемы со скриптами, то нужно просто переходить на какой-нибудь > более-менее типизированный язык с sh'а. Т.е. вполне можно взять и переписать > sysVinit скрипты с sh на тот же Ocaml. Они, конечно, распухнут, > но ошибок будет меньше. Хотя, конечно, это явно не идеальный выбор > языка - желательно всё-таки написать лёгкую типизированную замену sh. Кстати, очень интересная мысль. Предлагаю обсудить в почте. vkni@altlinux.org, не ошибаюсь? У меня есть некоторый опыт разработки DSL на Ocaml. Давайте обсудим и скооперируемся. Я бы поигрался с подобным проектом. Сейчас болею, но завтра-послезавтра буду в адеквате. Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы sysvinit решены в других инитах. Я лично с проблемами в скриптах не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно не хватает. > Но архитектура-то всё равно будет не systemDшная (кубик-рубик-монолит), а sysVinit'овская > - лёгкое ядро + скриптовая обвязка. И это хорошо.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	101. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Vkni (ok) on 01-Окт-16, 22:48
	> У меня есть некоторый опыт разработки DSL на Ocaml. У меня тоже есть, но толку-то? Основная проблема с заменой sh - это то, что нужно хорошо поставить задачу, описать этот самый язык. А интерпретатор много кто может написать. Я много раз это обсуждал - решительно непонятно, что конкретно нужно делать с типами. Т.е. с одной стороны, скриптовый движок должен быть типизирован (т.к. bash уже есть), с другой стороны, нужна поддержка grep/sed - т.е. операций над строковыми данными. Нужно, чтобы скрипт мог без выпадения обрабатывать потоки данных с ошибками. Вот что в bash'е круто: 1) Работа со файловыми именами без кавычек. Ну и вообще минимум кавычек. 2) Ленивость конвееров как Хаскелле, позволяет обрабатывать не влезающие в ОЗУ объёмы данных потоковым образом. 3) Распараллеливаемость всего и всея - программы, входящие в конвеер работают параллельно. > Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы > sysvinit решены в других инитах. Я лично с проблемами в скриптах > не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно > не хватает. Инит скрипты уже более-менее вылизаны. Ну, а что плохо - if'ы, передача параметров скриптам, передача кодов ошибок и т.д.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	103. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от freehck (ok) on 02-Окт-16, 15:57
	>> У меня есть некоторый опыт разработки DSL на Ocaml. > У меня тоже есть, но толку-то? Основная проблема с заменой sh - > это то, что нужно хорошо поставить задачу, описать этот самый язык. > А интерпретатор много кто может написать. > Я много раз это обсуждал - решительно непонятно, что конкретно нужно делать > с типами. Т.е. с одной стороны, скриптовый движок должен быть типизирован > (т.к. bash уже есть), с другой стороны, нужна поддержка grep/sed - > т.е. операций над строковыми данными. Нужно, чтобы скрипт мог без выпадения > обрабатывать потоки данных с ошибками. Вот мне тоже не понятно, куда там типизацию втыкать. Основное применение shell - это вызов внешних команд. А их коды возврата - это обычно int. И где мы там типизацию втыкать собрались... Нужна ли поддержка grep/sed в самом языке - это конечно вопрос интересный. Чтобы как в perl не ставить лишнюю экранировку - может быть, было бы удобно. Но возможно легче было бы в bash привнести что-то вроде двойных-тройных кавычек для этого дела? Но вот если Вы предлагаете регэкспы компилировать языком, то я считаю это однозначно плохой вещью. Пусть уж лучше sed разбирает строку, которую мы ему передали и сигналит об ошибке кодом возврата, как и раньше. Потом, начнём мы типы вводить. Какие мы сможем ввести-то? И для чего? Я смекаю, что только для определяемых функций. У нас будет тип exit_code, который будет либо Ok, когда программа вернула нуль, и Error of int, когда программа вернула не нуль. У нас будут преобразования exit_code в bool и в int. Надо поработать со строками обязательно. Где мы сможем использовать типизацию? Пожалуй, только в функциях, которые мы определяем в самом языке. Повсеместно будут требоваться преобразования кода возврата во что-нибудь. Для каждого действия со внешними командами придётся писать типизированную обёртку. Скрипты довольно-таки разрастутся. Если на то пошло, у меня похоже получается один-в-один Ocaml, который дёргает внешние команды. Но сам Ocaml использовать нельзя, потому что у него слишком большой рантайм. Нам нужно что-нибудь легковесное, что уместится килобайт в 20 против 170кб для hello_world для Ocaml. > Вот что в bash'е круто: > 1) Работа со файловыми именами без кавычек. Ну и вообще минимум кавычек. В большинстве случаев всё равно оборачиваю в кавычки всё, с чем работаю, чтобы в случае наличия пробелов трактовалось как один параметр. > 2) Ленивость конвееров как Хаскелле, позволяет обрабатывать не влезающие в ОЗУ объёмы > данных потоковым образом. Ленивость конвееров - это собственно не фишка самого shell, а фишка unix-системы в целом. Он же создаёт детей и связывает их каналами, так что распараллеливание, оно на уровне ядра, а не shell-а. > 3) Распараллеливаемость всего и всея - программы, входящие в конвеер работают параллельно. Аналогично п.2 >> Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы >> sysvinit решены в других инитах. Я лично с проблемами в скриптах >> не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно >> не хватает. > Инит скрипты уже более-менее вылизаны. Ну, а что плохо - if'ы, передача > параметров скриптам, передача кодов ошибок и т.д. А что там с if-ами? Не соображу никак. Если есть желание cond, так elsif в принципе та же фигня. Да и case в наличии. Передача параметров - возможно. В принципе аналоги labeled & optional parameters для скриптов можно было бы обязательным предварительным getopt-разбором. Хотя если честно, мне понравилось, как параметры разбираются в zsh. Получается примерно так: zparseopts -a opts \            v+ -version \            d -debug \            h -help -usage \            s:=server -server:=server \            -src:=source -source:=source \            -dst:=destination -destination:=destination \            p:=project -project=project \            a:=action -action:=action \            u:=user -user:=user
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	100. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Окт-16, 22:39
	> У вас там Левин есть. Я с ним не знаком Вообще это несложно поправить -- на конторе всё так же вечерами водится чай, а завтра до обеда мы вообще в Калуге на #ossdevconf (ещё можно в Переславль где-нить к концу января готовиться с докладом по образовательной тематике или просто так).  Ну, на всякий :) PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где неподалёку живёт -- в лицо друг дружку знать?..
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	102. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от freehck (ok) on 02-Окт-16, 15:25
	>> У вас там Левин есть. Я с ним не знаком > Вообще это несложно поправить -- на конторе всё так же вечерами водится чай, А контора-то где? > ещё можно в Переславль где-нить к концу января готовиться с докладом > по образовательной тематике или просто так. Посмотрел. Мне 4 часа ходу до Переславля. Можно попробовать. Хотя Москва была бы удобнее. Я не очень хороший водитель пока - 4 часа за рулём мне пока тяжело. :) > PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где > неподалёку живёт -- в лицо друг дружку знать?.. Очень за. Заодно может ключи друг другу подпишем (если кто пользуется gpg)?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	105. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Michael Shigorin (ok) on 03-Окт-16, 15:10
	>>> У вас там Левин есть. Я с ним не знаком >> Вообще это несложно поправить -- на конторе всё так же вечерами водится чай, > А контора-то где? На Дмитровской, см. basealt.ru. > Посмотрел. Мне 4 часа ходу до Переславля. Можно попробовать. Хотя Москва была > бы удобнее. Я не очень хороший водитель пока - 4 часа за рулём мне пока тяжело. :) Да, зимой по горкам с эпизодическими лесовозами бывает сложно -- но туда арендуют автобус. >> PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где >> неподалёку живёт -- в лицо друг дружку знать?.. > Очень за. Заодно может ключи друг другу подпишем (если кто пользуется gpg)? Тоже вариант, если кому надо.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

44. "Локальная DoS-уязвимость в systemd"	+4 +/–
Сообщение от anonymous (??) on 30-Сен-16, 08:23
Я все жду когда Торвальдс хороший гемор от этой поделки получит
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от Andrey Mitrofanov on 30-Сен-16, 09:31
	> Я все жду когда Торвальдс хороший гемор от этой поделки получит LF РедХейту гешефт не выклюет!
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

68. "Локальная DoS-уязвимость в systemd"	+1 +/–
Сообщение от Аноним84701 on 30-Сен-16, 17:42
> При поступлении сообщения нулевой длины в сокет уведомлений systemd, > PID 1 зависает на системном вызове pause Немного напомнило давний баг https://bugs.freedesktop.org/show_bug.cgi?id=74589 > systemd segfaults if no cgroups are available Вернее, ответ анонимного тезки Леннарту ) (Lennart) >> To make this work we'd need a patch, as nobody of us tests this. (Тезка) > Yes, it's clear you don't test for NULL pointers before deferencing. > Nobody else should need to provide a patch to fix the bug you created. > If you can't figure out how to check for NULL pointers, STOP WRITING CODE IMMEDIATELY! > You should never EVER be deferencing any pointer without first sanity checking its value. >NO EXCEPTIONS! > P.S. Please go diе in a fire. > Вообще, проверок и аccертов в том коде системд, который я просматривал, немало. Но как-то немного беccистемно. Т.е. иногда как минимум двойные-тройные, когда параметры проверяются вызывающей функцией, а потом еще и в вызванной. Ну и поведение кода в "случае чего" как-то ... не всегда очевидно (вернее, так далеко я в код  не закaпывался, так что воздержусь от опрометчивых суждений).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	69. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от KonstantinB (ok) on 30-Сен-16, 19:17
	Я тоже глубоко не закапывался, но на поверхностный взгляд "бессистемность" - это очень хорошая характеристика стиля кода systemd. Код upstart-а, по крайней мере, читать намного проще.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	72. "Локальная DoS-уязвимость в systemd"	–2 +/–
	Сообщение от anomymous on 30-Сен-16, 20:16
	upstart в целом был бы куда более интересен, если бы не имел такой полномасштабной жопы с отслеживанием разного рода зависимостей. В системды конфиги в целом логичны. А код - дело вылизываемое.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	88. "Локальная DoS-уязвимость в systemd"	+3 +/–
	Сообщение от Vkni (ok) on 01-Окт-16, 00:03
	> А код - дело вылизываемое. Можете приступать. Но что-то тот код с магическими константами как появился в 2010м году, так до сих пор торчит.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	90. "Локальная DoS-уязвимость в systemd"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Окт-16, 09:45
	> А код - дело вылизываемое. ...архитектура -- дело поправимое, задумка -- не беда... PS: привет с калужской конференции #ossdevconf :)
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	104. "Локальная DoS-уязвимость в systemd"	+/–
	Сообщение от KonstantinB (ok) on 02-Окт-16, 19:37
	Теперь-то да, деваться уже некуда. Пару лет назад еще имело смысл пробовать допилить upstart.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	76. "Локальная DoS-уязвимость в systemd"	–1 +/–
	Сообщение от Аноним (??) on 30-Сен-16, 20:32
	> Код upstart-а, по крайней мере, читать намного проще. А радости с этого? Ну вот надо мне чтобы моя программа взлетела перед какой-то еще программой. С апстартом - болт. Он это нормально не умеет by design. Для этого надо прописываться в конфиг той программы, а это уже разборки с тем как тот пакет обновляется и не перетрет ли он изменения. Системд этим не страдает.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема