The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"Локальная DoS-уязвимость в systemd"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Локальная 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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(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 email(ok) on 01-Окт-16, 09:47 
Ну и нахрена вам всё это?

> namespace переключить

Ну и что вам такого дали эти ваши namespace-ы? Улучшенная статистика? О, это да. Статистика - это ведь круто. "Типа контейнеризация, типа безопасность"? Да нет вроде. "Возможность управлять всеми процессами разом"? Блин, ну так для того всегда были pgid и sid у каждого процесса. Вы о них хотя бы слышали, оналитеги хреновы?

> расставляя лимиты

О да, ulimit-а вам почему-то не хватило.

> ... переключая планировщики ...

Планировщики по 10 раз на дню переключать. Ага. Зачем?! Кому такое в голову взбрело, что за больное воображение? Кроме вас, системдэ-шников, так *никто* не делает.

> ... лимиты SECCOMP ...

"Запихнём всё в контейнеры во имя добра"?

Как же блин раньше-то люди жили без этих песочниц-то? Пихали процесс в chroot и горя не знали. И то - при крайней необходимости, и только.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

95. "Локальная DoS-уязвимость в systemd"  +/
Сообщение от Michael Shigorin email(ok) on 01-Окт-16, 11:37 
>> расставляя лимиты
> О да, ulimit-а вам почему-то не хватило.

Он скорее о том, что ulimit из инитскриптов в "обычных дистрибутивах" штатно не дёргается, т.е. придавить получится лишь с точностью до псевдопользователя в тех случаях, когда на них вообще переключаются.  Дистрибутивно решается крайне компактной шелльной библиотекой (ссылка в #93) и точечными добавлениями в собственно пакетах с сервисами.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

96. "Локальная DoS-уязвимость в systemd"  +2 +/
Сообщение от freehck email(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 email(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 email(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 email(ok) on 01-Окт-16, 22:39 
> У вас там Левин есть. Я с ним не знаком

Вообще это несложно поправить -- на конторе всё так же вечерами водится чай, а завтра до обеда мы вообще в Калуге на #ossdevconf (ещё можно в Переславль где-нить к концу января готовиться с докладом по образовательной тематике или просто так).  Ну, на всякий :)

PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где неподалёку живёт -- в лицо друг дружку знать?..

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

102. "Локальная DoS-уязвимость в systemd"  +/
Сообщение от freehck email(ok) on 02-Окт-16, 15:25 
>> У вас там Левин есть. Я с ним не знаком
> Вообще это несложно поправить -- на конторе всё так же вечерами водится чай,

А контора-то где?

> ещё можно в Переславль где-нить к концу января готовиться с докладом
> по образовательной тематике или просто так.

Посмотрел. Мне 4 часа ходу до Переславля. Можно попробовать. Хотя Москва была бы удобнее. Я не очень хороший водитель пока - 4 часа за рулём мне пока тяжело. :)

> PS: коллеги, а может, учиним при случае опеннетовку, чтоб хоть кто где
> неподалёку живёт -- в лицо друг дружку знать?..

Очень за. Заодно может ключи друг другу подпишем (если кто пользуется gpg)?

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

105. "Локальная DoS-уязвимость в systemd"  +/
Сообщение от Michael Shigorin email(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 email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру