The OpenNET Project / Index page

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

Уязвимость в systemd, которую можно использовать для блокирования работы системы

19.02.2019 10:12

В systemd найдена уязвимость (CVE-2019-6454), позволяющая вызвать крах управляющего процесса инициализации (PID1) через отправку непривилегированным пользователем специально оформленного сообщения через шину D-Bus. Разработчики из Red Hat также не исключают возможность применения уязвимости для организации выполнения кода с привилегиями root, но окончательно возможность такой атаки пока не определена.

Манипулируя размером отправляемого через D-Bus сообщения атакующий может сместить указатель за границы выделенной для стека памяти, обойдя защиту "stack guard-page", суть которой в подстановке на границе со стеком страниц памяти, обращение к которым приводит к генерации исключения (page-fault). По мнению исследователя безопасности, выявившего уязвимость, смещение указателя стека возможно только на неиспользуемые страницы памяти (unmapped), что не позволяет организовать выполнение кода в контексте процесса PID1, но даёт возможность атакующему инициировать крах PID1 с последующим переходом ядра Linux в состояние "panic" (в случае краха обработчика PID 1, происходит крах всей системы).

В systemd устанавливается обработчик сигналов, пытающийся перехватить крахи процесса PID1 (segmentation fault) и запускающий shell для восстановления. Но так как в ходе атаки обращение производится к неотражённым страницам памяти (unmapped), ядро не может вызвать данный обработчик сигнала и просто завершает процесс с PID 1, что, в свою очередь, приводит к невозможности продолжения дальнейшей работы и переходу в состояние "panic", требующего перезапуска системы.

Обновления пакетов с устранением уязвимости опубликованы для SUSE/openSUSE, Fedora, Ubuntu и частично для Debian (только для Debian Stretch). Проблема остаётся неисправленной в RHEL. Успешная атака продемонстрирована в Ubuntu 18.10 с systemd 239 и в CentOS 7.6 с systemd 219. В качестве обходного пути защиты может использоваться сборка в GCC c включением опции "-fstack-clash-protection", которая по умолчанию применяется в Fedora 28 и 29.

Следует отметить, что в 2014 году автор системной библиотеки musl выделял среди основных архитектурных проблем systemd излишнюю раздутость обработчика PID1 и ставил под сомнение целесообразность реализации обработчика DBus API на уровне PID1, так как он является серьёзным вектором для проведения атак и может негативно влиять на надёжность всей системы.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: В systemd-journald выявлены три уязвимости, позволяющие получить права root
  3. OpenNews: Раскрыты детали атаки Stack Сlash и 15 root-эксплоитов для разных ОС
  4. OpenNews: Спорная ошибка в systemd, позволяющая повысить привилегии, закрыта без исправления
  5. OpenNews: Архитектурные проблемы systemd, негативно влияющие на стабильность и безопасность
  6. OpenNews: Участник проекта Debian ответил на критику systemd
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: systemd, stackclash
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (224) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (1), 10:21, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +46 +/
    > В systemd устанавливается обработчик сигналов,
    > пытающийся перехватить крахи процесса PID1...
    > ядро не может вызвать данный обработчик сигнала
    > и просто завершает процесс с PID 1

    Очевидно, для решения проблемы потребуется systemd-kerneld.

     
     
  • 2.48, zzz (??), 11:54, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +18 +/
    А кто тогда будет отрабатывать сегфолты в systemd-kerneld? Не подумали? А ведь это тоже вектор атаки.

    Для защиты systemd-kerneld от подобного необходимо устанавливать систему в гипервизор systemd-hvd. А для купирования проблемы возможного сегфолта systemd-hvd, прикрутим ему аппаратный systemd-monitd.

    В итоге мы получим вполне рабочую систему - за systemd присматривает systemd-kerneld, за которым присматривает гипервизор systemd-hvd, за которым присматривает systemd-monitd. Вот это уже похоже на нормальную систему инициализации, не то, что эти сисвишные портянки.

     
     
  • 3.68, Michael Shigorin (ok), 12:35, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > А кто тогда будет отрабатывать сегфолты в systemd-kerneld?

    NOTABUG!

     
     
  • 4.190, Аноним (1), 06:39, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    assert спасёт гиганта мысли
    [CODE]
    +/* Note that the D-Bus specification states that bus paths shall have no size limit. We enforce here one
    + * anyway, since truly unbounded strings are a security problem. The limit we pick is relatively large however,
    + * to not clash unnecessarily with real-life applications. */
    +#define BUS_PATH_SIZE_MAX (64*1024)

             /* Second, add fallback vtables registered for any of the prefixes */
    -        prefix = alloca(strlen(path) + 1);
    +        pl = strlen(path);
    +        assert(pl <= BUS_PATH_SIZE_MAX);
    +        prefix = new(char, pl + 1);
    +        if (!prefix)
    +                return -ENOMEM
    [/CODE]

    https://github.com/systemd/systemd/commit/798ebaf9aea9b8ae3b8a0cc2702bc8de71ac

     
  • 3.153, Аноним (1), 16:33, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А кто тогда будет отрабатывать сегфолты в systemd-kerneld?

    В ядре нет сегфолтов. Там ловушки и прерывания. В данном случае double fault (это отдельный тип - abort, невосстанавливаемая ошибка). При этом юзерланд "сделал всё что мог". Появился повод говорить об ошибке дизайна в ядре. Так что в исходном сообщении не то что бы шутка. Как и в предложении запилить systemd-hvd.

     
  • 3.165, Пользователь (?), 18:24, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > за systemd присматривает systemd-kerneld, за которым присматривает гипервизор systemd-hvd, за которым присматривает systemd-monitd

    Во всей этой лабуде уязвимостей не может быть в принципе?
    > это уже похоже на нормальную систему инициализации

    Сломал одно, а остальное посыпется уже само по себе.

     
  • 2.175, xm (ok), 23:17, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну то есть смерть PID 1 настолько нормальная ситуация с systemd что они даже обработчик штатный написали. Надёжность!
     
     
  • 3.189, Аноним (1), 06:36, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Отправка сигнала извне это штатная ситуация или нет? Надо ли её предусмотреть и обработать?

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

     
  • 1.2, Аноним (2), 10:23, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Всёравно notabug!1111
     
  • 1.3, EuPhobos (ok), 10:23, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > Обновления пакетов с устранением уязвимости опубликованы для

    А в devuan исправили уже?

     
     
  • 2.5, Аноним (5), 10:26, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    жырно
     
  • 2.6, Andrey Mitrofanov (?), 10:27, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +21 +/
    >> Обновления пакетов с устранением уязвимости опубликованы для
    > А в devuan исправили уже?

    Давно!
    [CODE]
    25.05.2017 22:51  Первый релиз Devuan, форка Debian без systemd

     
  • 2.7, freehck (ok), 10:29, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Обновления пакетов с устранением уязвимости опубликованы для
    > А в devuan исправили уже?

    Исправили ещё до первого релиза. Ваш кэп. =)

     
  • 2.20, Аноним (20), 11:10, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Там установочные образы год не перестают, так что без этого в диване форменное шерето.
     
     
  • 3.70, Michael Shigorin (ok), 12:36, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Там установочные образы год не перестают

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

     
     
  • 4.76, Аноним (20), 12:48, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это т9. Пересоберут, разумеется.
     
     
  • 5.147, Michael Shigorin (ok), 15:56, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Это т9. Пересоберут, разумеется.

    Где, в логике (точнее, её отсутствии, как в #142 и интересуются)?

     
  • 3.142, Аноним (142), 15:25, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А вы после развёртывание образа сразу начинаете пользоваться системой без установки обновлений?
     
     
  • 4.144, Andrey Mitrofanov (?), 15:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А вы после развёртывание образа сразу начинаете пользоваться системой без установки обновлений?

    В необновлённом APT, который их, обновления, и скачивает-устанавливает, с этими самыми скачиваниями есть  известная уязвимость.

    Debian-ы выпустили "экстренный" поинт-релиз  -- в т.ч. установочные CD/DVD с исправленным APT.

    У Devuan-а поинт-релизы и исправления .iso-шников "не практикуются".
    https://www.opennet.ru/openforum/vsluhforumID3/116383.html#44

    Ресурсов мало, инфраструктура недокручена или ещё что...

    ...особо невыдержанные анонимы считают, что от этого "в диване форменное шерето".  Слабаки[I]!

     
     
  • 5.183, Gannet (ok), 01:58, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, крутые посоны лёгких путей не ищут!
     
  • 2.159, Vkni (ok), 17:29, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это безусловно чудесный дистрибутив, исправляющий не только прошлые, настоящие, но даже будущие ошибки systemd.

    Кстати, Михаил в отдельных сборках ALT тоже превентивно исправил эту и многие другие проблемы системы инициализации с раздутым PID 1.

     
     
  • 3.163, Michael Shigorin (ok), 18:16, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, Михаил в отдельных сборках ALT тоже превентивно исправил эту
    > и многие другие проблемы системы инициализации с раздутым PID 1.

    Это далеко не только моё дело, спасибо коллегам.

    PS 2 WSJSoldier: фу так позориться -- фейки разносить.

     
  • 2.182, Gannet (ok), 01:55, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дебоян безбажный в принципе, ты чо?
     
  • 1.9, Аноним (9), 10:36, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    > целесообразность реализации обработчика DBus API на уровне PID1, так как он является серьёзным вектором для проведения атак и может негативно влиять на надёжность всей системы.

    С одной стороны, а с другой стороны, как я понял из истории этого проекта они хотят иметь всесистемную единую систему IPC/RPC через протокол DBus, которая также должна быть и представлена и в ядре Linux (но патчи пока завернули). Например, чтобы добиться паритета в функциях с той же вендой, но сделать лучше, потому что у венды IPC/RPC это легаси и история. Как обычно, новый функционал = новые уязвимости.

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

     
     
  • 2.12, Аноним (-), 10:54, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Даже если процессу с PID 1 зачем-то нужно получать сообщения из DBus (что само по себе вопрос), он мог бы их получать через пайп от одного из дочерних процессов уже частично обработанными.
     
     
  • 3.15, пох (?), 10:57, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    какой еще пайп, вы еще предложите на перфокартах.
    Это не стильно, не модно и не молодежно, когда у нас есть libdbus!
     
     
  • 4.18, Andrey Mitrofanov (?), 11:06, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > какой еще пайп, вы еще предложите на перфокартах.
    > Это не стильно, не модно и не молодежно, когда у нас есть
    > libdbus!

    Не-не, где, панимаишь, REST-http-API в ядре и pid1, когда он нужен!?

     
     
  • 5.27, Лёня Потный (?), 11:20, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    это в планах. Не столь отдаленных, хахаха!

     
     
  • 6.35, Andrey Mitrofanov (?), 11:28, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > это в планах. Не столь отдаленных, хахаха!

    Да, понятно.  :Q  Rest поверх http поверх ip gоверх qr-кодов.

     
     
  • 7.102, Аноним (-), 13:28, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот из-за таких как вы BUS1 в ядро и не принимают!!1
     
     
  • 8.148, Andrey Mitrofanov (?), 16:02, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот из-за таких как вы BUS1 в ядро и не принимают!!1

    Спасибо, конечно.  Но, уверяю, Вы преувеличиваете мои скромные заслуги.

     
  • 6.139, Аноним (142), 15:14, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На Node.js?
     
     
  • 7.146, Andrey Mitrofanov (?), 15:53, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > На Node.js?

    ...на BUS1 на eBPF...

     
  • 2.13, пох (?), 10:54, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну да, зачем обращать внимание на комментарии - они за вас уже все решили, и премию от отдела глубокого зондирования rhibm уже получили.

    Сделаем как в винде, только всем хуж...ой, простите, только гораздо лучше, мы ж куда умнее и продвинутее! Вот например какие классные эксплойты...правда, в винде уже тоже было, году так в 98м, но мы обещаем догнать и перегнать!

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

     
     
  • 3.16, Аноним (9), 11:00, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Яда в комментарии много, а смысл, как мне кажется именно тот же, какой я вложил в первый комментарий.
    И да, линуксу не достаёт функций которые были еще в NT4, со стороны базовой системы инфраструктура отсталая.
     
     
  • 4.29, пох (?), 11:22, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    линуксу НЕ НУЖНЫ "функции которые были в NT4" - те, кому они нужны, могут распаковать архив с nt4 и наслаждаться, если что-то кроме жадности помешало вам это сделать в 1997м году, раз они вам были нужны. Мне вот они были не нужны, поэтому у меня был - линукс, а не NT4.

    А вот сегодня тем кому нужна нормальная юникс-стайл система без "как в NT4" - бежать уже вообще некуда.

     
     
  • 5.52, zzz (??), 11:59, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как это некуда бежать? Есть отличная FreeBSD, куда тащат не корпоративную отрыжку, а годноту вроде ZFS или sendfile async io
    https://www.opennet.ru/opennews/art.shtml?num=43646
     
     
  • 6.75, Дон Ягон (?), 12:44, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    ZFS - это не корпоративная отрыжка? С чего бы?
    FreeBSD давно уже стремится стать линуксом (который стремится стать виндой). Ничего интересного.
    Только OpenBSD.
     
  • 6.77, Дон Ягон (?), 12:49, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > В состав FreeBSD принята высокопроизводительная реализация sendfile от Netflix
    > Netflix
    > куда тащат не корпоративную отрыжку

    мда.

     
  • 6.94, пох (?), 13:13, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    как это не тащат Вам же только что показали кино про страдания молодого Оно что... текст скрыт, показать
     
  • 5.73, Michael Shigorin (ok), 12:39, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот сегодня тем кому нужна нормальная юникс-стайл система
    > без "как в NT4" - бежать уже вообще некуда.

    А вот кстати, ми-минор-коробку не видали?

    http://emboxing.ru/

    Оно, конечно, в первую очередь под эмбедщину -- зато наше и нежирное.

     
     
  • 6.84, Andrey Mitrofanov (?), 12:56, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> А вот сегодня тем кому нужна нормальная юникс-стайл система
    >> без "как в NT4" - бежать уже вообще некуда.
    > А вот кстати, ми-минор-коробку не видали?
    > http://emboxing.ru/
    > Оно, конечно, в первую очередь под эмбедщину -- зато наше и нежирное.

    И под GPLv3+ !  Точно, Наше Всё.  Дайте два.

    ...а не, 2-clause permissive и универ-копирайт.  Ладно.  "Как в НТ4" на подходе, да-да, конечно.

     
     
  • 7.101, Michael Shigorin (ok), 13:27, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > И под GPLv3+ !  Точно, Наше Всё.  Дайте два.

    Так авторам можно написать -- ну отгрузят под v3+.

     
     
  • 8.108, Andrey Mitrofanov (?), 13:48, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Так авторам можно написать -- ну отгрузят под v3+.

    Мне-то не надо.   И не отгрузят -- зечем им лишние _обязательства_ и проблемы.

     
  • 5.74, Дон Ягон (?), 12:41, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    OpenBSD
     
  • 5.104, Аноним (1), 13:32, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > линуксу НЕ НУЖНЫ "функции которые были в NT4"
    > те, кому они нужны, могут распаковать архив с nt4 и наслаждаться

    Вообще-то "как в NT4" мало кто из знатоков buzzwords представляет, так как документировано оно не для всех. И уж точно предлагавший удивится, узнав, что какая-нибудь CreateMailslotA() появилась позже и в тамошнем аналоге WinE.

     
  • 4.173, Аноним (173), 21:40, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что за функции в нт4?
     
  • 3.26, Аноним (26), 11:19, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    иди уже нафиг со своей виндой. достал.
     
     
  • 4.46, Аноним (-), 11:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не нравится винда - смотри на макось. Макось - настоящий UNIX, но без launchd в нём тоже не обошлись.
     
     
  • 5.80, Michael Shigorin (ok), 12:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Макось - настоящий UNIX

    Не настоящий, а сертифицированный -- разницу понимать надо.

     
  • 2.17, Crazy Alex (ok), 11:03, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    на фиг не нужно в pid 1 заниматься абсолютным большинством того, что туда в systemd напихали. Тогда и общаться с ним по d-bus не понадобится.
     
     
  • 3.19, Аноним (9), 11:09, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > никто из разработчиков не обращает внимания на такие комментарии. Потому что это предложение НЕ делать чего-нибудь и отказаться от изначальной задачи. Комментарий не предлагает как решить.
     
  • 3.22, Andrey Mitrofanov (?), 11:13, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > на фиг не нужно в pid 1 заниматься абсолютным большинством того, что
    > туда в systemd напихали. Тогда и общаться с ним по d-bus
    > не понадобится.

    Ах, коллега, опять Вы со своим "не нужно".

    Аудитория ж верит (вкерует?!), что вот-вот уже-уже почти-почти должны всенепрпеменно подвезти....

    ...всеобщее процветание и проблагоухание.

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

    </таймшер недорого без смс>

     
  • 3.25, Аноним (9), 11:18, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Есть 2 демона. Один демон предпримет действия если потребление ресурсов машины такое-то такое-то (придумайте метрику) о чём оповестит второго демона.

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

     
     
  • 4.57, Совершенно другой аноним (?), 12:05, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    IPC и RPC в linux, по-моему, не меньше, чем в Windows. И уже довольно давно. Начиная с разных там SUN-RPC.
     
     
  • 5.60, Аноним (9), 12:10, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да их много и ни одного рабочего стандартизированного варианта.
     
     
  • 6.67, Совершенно другой аноним (?), 12:34, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Да их много и ни одного рабочего стандартизированного варианта.

    в смысле? Что Вы понимаете под стандартизироваными? Тот-же SUN-RPC вполне себе есть практически везде - на нём основан NFS (и была реализация в Windows в Windows Services for Unix). А по поводу IPC - тех-же самых BSD-сокетов - так они даже в Windows такие-же, с поправкой на необходимую инициализацию, функцию closesocket()/ioctlsocket() и WSAGetLastError(). Прочих IPC тоже хватает - начиная с обычных FIFO и PIPE-ов, продолжая стандартными posix-овскими семафорами, очередями сообщений, мутексами, разделяемыми областями памяти. Которые более-менее одинаковые во всех UNIX-системах, как в BSD, LINUX и даже в разных там QNX. Кроме того есть ещё и классические unix-ipc, которые тоже до сих пор вполне себе работают и тоже много где поддерживаются.

     
     
  • 7.86, Andrey Mitrofanov (?), 12:58, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Да их много и ни одного рабочего стандартизированного варианта.
    > в смысле? Что Вы понимаете под стандартизироваными?

    Шоб Керниган и друг его IETF в книжку про Си вписали.  Рядом с hello-миром.


    >Тот-же SUN-RPC вполне себе есть
    > практически везде

     
     
  • 8.90, Совершенно другой аноним (?), 13:03, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>> Да их много и ни одного рабочего стандартизированного варианта.
    >> в смысле? Что Вы понимаете под стандартизироваными?
    > Шоб Керниган и друг его IETF в книжку про Си вписали.  
    > Рядом с hello-миром.

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

     
  • 8.121, Совершенно другой аноним (?), 14:33, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Прошу прощения, не совсем понял Вашу мысль Те-же PIPE-ы и FIFO вполне себе дос... текст скрыт, показать
     
  • 2.23, Аноним (1), 11:13, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > у венды IPC/RPC это легаси и история.

    И что там теперь вместо APC и completion routines? Может и DISPATCH_LEVEL стал историей?

     
  • 2.55, Аноним (55), 12:02, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > чтобы добиться паритета в функциях с той же вендой

    Нафейхоа? «Паритет» это вообще что в данном контексте? Встроенную спайварь тоже будем добавлять?

     
     
  • 3.61, Аноним (9), 12:14, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да, причём уже. https://www.bleepingcomputer.com/news/linux/ubuntu-reveals-desktop-telemetry-f
     
  • 2.275, Дон Ягон (?), 00:42, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > И тут примечательно, почему никто из разработчиков не обращает внимания на такие комментарии.

    Давай будем честны - не только на такие. Увы, это лишь характеризует их как высокомерных зазнаек.

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

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

    > Комментарий не предлагает как решить.

    Вообще-то предлагает.

     
     ....нить скрыта, показать (40)

  • 1.10, Аноним (10), 10:38, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    может это не проблема systemd, а проблема о.с.?
    может проще написать о.с. systemd-system?
     
     
  • 2.14, пох (?), 10:55, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    так уже, systemd/Linux называется.

    "ваш новый стандарт".

     
  • 2.172, Hellraiser (??), 21:13, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    systemd-system не звучит; то ли дело - потерингукс
     
  • 1.21, Аноним (-), 11:10, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >thread 'main' has overflowed its stack
    >fatal runtime error: stack overflow
    >Aborted

    Так было бы если бы systemd был написан на Rust.

     
     
  • 2.24, Аноним (24), 11:17, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Леню бы задолбали варнинги с ошибками и он написал бы свой, принципиально новый конпелятор раста :)
     
     
  • 3.81, anon234 (?), 12:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    systemd-rust?
     
     
  • 4.129, CrossOver (?), 14:45, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    systemd-rust-runtime-sdk
     
  • 2.31, пох (?), 11:24, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Так было бы если бы systemd был написан на Rust.

    как запилите хотя бы версию 1 (не 0.0.1, учитесь у Лёни) - с меня донейт.

     
     
  • 3.34, Аноним (-), 11:28, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А смысл? Паника будет так и так.
     
     
  • 4.37, пох (?), 11:29, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А смысл? Паника будет так и так.

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

     
  • 1.28, Аноним (28), 11:20, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > ядро не может вызвать данный обработчик сигнала и просто завершает процесс с PID 1

    Ещё и в ядре ошибка.

     
     
  • 2.33, пох (?), 11:27, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    это не ошибка, это системная функция, точнее, ее отсутствие - ядро писал ретроград Линус двадцать пять лет назад, когда процесс с pid1 к "unmapped памяти" не обращался, поскольку вообще занимался исключительно своим делом - запуском демонов и сбором мусора.

     
     
  • 3.47, Аноним (9), 11:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    ...а потом еще спрашивают, почему разработчики systemd вечно норовят залезть в ядро. Ясно-понятно почему, устаревшая забагованная ерунда с кучей никому не нужных древних ФС (федора их уже выпилила), археологических драйверов, которые сто лет никто не собирает и дальше по тексту. Надо приводить в порядок эту помойку под нужды современного бизнеса.
     
     
  • 4.72, Andrey Mitrofanov (?), 12:38, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ...а потом еще спрашивают, почему разработчики systemd вечно норовят
    >Надо приводить в порядок эту
    > помойку под нужды современного бизнеса.

    " Можете форкать! "

    Денег у вас завались, времени девать некуда.  Вперёд[I]!

     
     
  • 5.97, пох (?), 13:20, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>Надо приводить в порядок эту
    >> помойку под нужды современного бизнеса.

    ну в общем-то давно уже за это взялись
    > " Можете форкать! "

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

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

     
  • 4.194, Адекват (ok), 09:13, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ты что? как это выкинуть устаревшие драйверы ?? а как же сканеры, которые подключаются по LPT и сканируют со скоростью 1 лист за 4 часа ??? - много у кого из линуксоидов такие есть, и пусть там пара вертикальных полос идет и цвето-передача страдает, так РАБОТАЕТ ЖЕ!!! и новый покупать не нужно!! Просто после сканирования еще 4 часа на правку в гимпе потратить и все норм будет!
     
     
  • 5.258, пох (?), 17:30, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ты думаешь, мой ls4000 (ни разу не lpt, а очень даже красивый, хотя и мертвый, firewire) в линуксе вообще как-то будет работать?

    И новый купить, что характерно - не получится.

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

    Ни задаром, ни за деньги, ни даже за бесконечно большие деньги.

     
     
  • 6.263, Michael Shigorin (ok), 19:24, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ты думаешь, мой ls4000 (ни разу не lpt, а очень даже красивый,
    > хотя и мертвый, firewire) в линуксе вообще как-то будет работать?

    Очень рекомендую VueScan, проверено на Nikon Coolscan 5000 тоже с IEEE1394.
    Автор, кстати, немного по-русски понимает :-)

     
  • 3.193, Аноним (1), 08:54, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > это не ошибка, это системная функция, точнее, ее отсутствие - ядро писал
    > ретроград Линус двадцать пять лет назад, когда процесс с pid1 к
    > "unmapped памяти" не обращался

    Да не в этом там дело. Там alloca


     
  • 3.200, Аноним (28), 11:20, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я про обработчик SIGSEGV, который ядро судя по новости то вызывает, то нет.
     
  • 1.30, iv (?), 11:23, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вот сейчас мы и узнаем, что из себя представляют разработчики systemd на самом деле. Если к 242 они выпилят из кодовой базы все выделяемые на стеке массивы переменной длины, то не всё ещё потеряно.
     
  • 1.32, Аноним (32), 11:25, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    не являясь хейтером systemd, часто задаюсь вопросом, зачем это абсолютно сырое, необкатанное и забагованное поделие пропихивают с таким скрипом в дефолт? ну валялось бы, где-нибудь в репах и вызревало. смотрю на работу мантейнеров дебиан, как они с ним откровенно говоря я***буца... ну не в какие рамки же
     
     
  • 2.36, пох (?), 11:28, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вы там вот выше прочитайте детскую радость очередного любителя "как в винде", сразу и поймете.

    А что, по вашему, разработчики дистрибутивов какие-то другие, им не хочется того же самого?

     
     
  • 3.43, Аноним (9), 11:47, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вот ты так говоришь "как в винде", будто в этом есть что-то плохое...
    А ведь меинтейнеры некоторых дистрибутивов на него перешли не просто так, что-то же им там понравилось.
     
     
  • 4.62, yet another anonymous (?), 12:16, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо, было предложение, от которого они не смогли отказаться?
     
  • 4.123, Аноним (123), 14:37, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Вот ты так говоришь "как в винде", будто в этом есть что-то плохое...

    Нет ничего в этом плохого, за исключением того, что в В-нде это есть уже давно и без всяких каков. Соответственно кому это было надо (или хотя бы просто устраивало) - давно уже на ней. А другие ОСи ценились именно за то, что они другие, что там не "как в В-нде". А зачэм нам два Сынавских?

     
  • 2.39, Andrey Mitrofanov (?), 11:34, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > не являясь хейтером systemd, часто задаюсь вопросом, зачем

    Ну, и чего надумал, не томи?
      " Не даёт ответа. "(ц)Гоголь  ?

     
     
  • 3.41, Аноним (32), 11:43, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    продолжаю наблюдения, почитывая openbsd юзер гайд
     
  • 2.40, Анонимочкин (?), 11:39, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Не ошибается только тот, кто ничего не делает.
    Нет ни одного серьёзного программного продукта, в котором бы отсутствовали баги.
    И чем более распространён и полезен продукт, тем чаще в нём будут выявлять уязвимости.

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

     
     
  • 3.83, Совершенно другой аноним (?), 12:52, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gt оверквотинг удален э прошу прощения, но у Вас, с таким подходом будет мик... текст скрыт, показать
     
     
     
    Часть нити удалена модератором

  • 5.103, Совершенно другой аноним (?), 13:28, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > systemd не монолитный и состоит из набора несвязанных между собой сервисов, каждый
    > из которых можно заменить на аналог или вообще удалить. Но обычно
    > - да, будет использоваться весь набор библиотек одного поставщика.

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

    > В состав systemd не входят драйверы.

    Зато входят DHCP-, DNS-сервера, генератор QR-кодов и прочие незаменимые в домашнем хозяйстве вещи.

     
     
     
    Часть нити удалена модератором

  • 7.132, Совершенно другой аноним (?), 14:52, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Которые непонятно зачем написаны, ведь есть аналоги, которые были ещё задолго до systemd.
    > Вы либо крайне саркастичны в своём комментарии либо... пфффф... вы серьёзно не
    > знаете зачем они там написаны? За тем, чтобы стандартизировать реализацию определённой
    > функции внутри базовой системы.

    Боюсь, кроме vendor-lock (c)(tm) ничего на ум не приходит.

    > Например: Система логгирования в системе ЕСТЬ. У неё апи такое-то. Если пользователь
    > заменил систему логирования на альтернативную, то она всё равно ЕСТЬ и
    > апи сохраняется. Теперь логгирование в этом примере замените на DHCP-клиент, кэширующие
    > DNS-резолвер и так далее и тому подобное.

    И до этого система логирования, ака syslog имела стандартизированный интерфейс. И система DNS, если вы про прикладной доступ.

     
  • 5.106, Michael Shigorin (ok), 13:38, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > systemd не монолитный и состоит из набора несвязанных между собой сервисов,
    > каждый из которых можно заменить на аналог или вообще удалить.

    Это очередной постулат или проверяли на себе?

     
  • 5.120, Аноним84701 (ok), 14:31, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > systemd не монолитный и состоит из набора несвязанных между собой сервисов, каждый  из которых можно заменить на аналог или вообще удалить.

    И на что можно заменить systemd-logind? А systemd-networkd? А mdev/eudev вместо systemd-udev будет работать?

     
  • 5.131, Аноним (131), 14:48, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ну? Даже udev можно открутить?
     
  • 4.92, Аноним (9), 13:09, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > микроядерная ОС с монолитным systemd

    ой это вряд ли, речь идёт просто о грибридном подходе, когда часть ядра в нулевом кольце, и куча всего в юзерспейсе. Там и подходы разные, вон есть Darwin, BSD, Windows NT и куча других ОС, которые используют этот подход.

    Да. Linux скоро превратится в BSD со своим оригинальным ядром. И я не вижу, чтобы Линус был против.

     
     
  • 5.105, Совершенно другой аноним (?), 13:38, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> микроядерная ОС с монолитным systemd
    > ой это вряд ли, речь идёт просто о грибридном подходе, когда часть
    > ядра в нулевом кольце, и куча всего в юзерспейсе. Там и
    > подходы разные, вон есть Darwin, BSD, Windows NT и куча других
    > ОС, которые используют этот подход.

    это-то понятно, просто продолжил мысль, изложенную в "проблеме 2" в исходном посте Анонима, ну и немного утрировал. Просто у него так получалось, что надо выкидывать функционал из ядра и впихивать в systemd. Хотя.. наверное я таки, наверное, за. Надеюсь, что при таком подходе systemd рухнет под своим весом гораздо раньше.. Вполне вероятно похоронив всех, кто окажется в непосредственной близости. Может даже и всех нас.

     
  • 4.96, Andrey Mitrofanov (?), 13:16, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >К сожалению, золотой век с монолитной ОС и
    > обычным sysvinit уже миновал...

    " Немое кино уже кончилось, а звуковое ещё не началось. "

    Так вот и мучаемся с сабжом, ага.  ><<<W>

     
  • 3.87, Аноним (9), 12:58, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наконец-то островок адекватности на опеннете Я согласен, что это логичный спосо... текст скрыт, показать
     
     
     
    Часть нити удалена модератором

  • 5.107, Аноним (9), 13:48, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Линуса, Столмана и идеологию в одно предложение ставить - фактическая ошибка. Послушайте хотя бы Q&A Sessions с Линусом и послушайте, что он думает про FSF, их идеологию и GPLv3.
    Юзерспейс - это ring 3, ничего тут вольного нет.
    Нвидия. Ну хотя бы эти источники дай, я поизучаю. Просто если компания:
    1) Отказывается предоставлять поддержку своему покупателю по оптимусу
    2) Выдаёт лицензионные проблемы своих патчей за технические проблемы
    То это не проблема Линуса, это проблема нвидии, которую она должна сама решить.
     
  • 4.166, Аноним (166), 18:40, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще этот спор монолитности и микроядерности так и не завершился, но
    > бизнес выбрал нечто среднее между ними и мне не известно, чтобы
    > кто-то продолжал финансирования экспериментов.

    ну есть L4 например. Кому надо попиливают

     
  • 3.89, Andrey Mitrofanov (?), 13:01, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Затем, что реализовать на базе монолитной ОС (коей сейчас является Линукс) современную
    > функциональность становится с

    Прогресс не остановить.  s-d-mikrocerneld в каждый дом,  шагает по планете.  Будет только хуже.  Вступайте в Автодор! </>

     
     
  • 4.99, пох (?), 13:25, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Прогресс не остановить.  s-d-mikrocerneld в каждый дом,  шагает по планете.

    может, кто-то еще успеет с планеты куда-нибудь свалить?

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

     
  • 4.116, Аноним (9), 14:17, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > s-d-mikrocerneld

    Таки ви пrедлагаете запилить поддержку GNU/Hurd?

     
     
  • 5.135, Andrey Mitrofanov (?), 14:56, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> s-d-mikrocerneld
    > Таки ви пrедлагаете запилить поддержку GNU/Hurd?

    Нет.  Зюстемдешнутым это не подойдёт:

    + В нём слишком много bash.  + В нём недостаточно LGPL.  + Опознавание своих по прыщам и веснушкам не проходит.

     
  • 3.134, Аноним (142), 14:54, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >микроядро + сервисы (systemd)

    Hurd, Genode обходятся микроядро + сервисы. Systemd им как собаке пятая нога.

     
  • 3.195, Адекват (ok), 09:19, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Не ошибается только тот, кто ничего не делает

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

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

     
  • 2.197, Онаним (?), 09:37, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что портянки ещё более сырых, забагованных и вообще недоделанных инит-скриптов достали всех.
     
     
  • 3.201, Аноним (28), 11:30, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Никто не запрещает использовать протестированные, без ошибок и полностью доделанные инит скрипты.
     
  • 1.42, Отражение луны (ok), 11:45, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Ну да, а еще можно просто отожрать под непривилегированным юзером nГб рамы, и система все так же умрет. Иными словами, сценария применения у уязвимости нет пока не доказана возможность выполнить код от рута.
     
  • 1.110, Аноним (110), 13:56, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    При init-е такого не было!!!
     
  • 1.125, Аноним84701 (ok), 14:38, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    >  позволяющая вызвать крах управляющего процесса инициализации (PID1) через отправку непривилегированным
    > пользователем специально оформленного сообщения через шину D-Bus.

    Никогда ж такого ж не было!
    Ой, было
    https://www.opennet.ru/opennews/art.shtml?num=45244
    > 29.09.2016 19:49  Локальная DoS-уязвимость в systemd
    > В системном менеджере systemd выявлена локальная уязвимость. Процесс PID 1 зависает на системном вызове pause() при поступлении в сокет уведомлений systemd
    >[...] любые локальные пользователи могут вызвать отказ в обслуживании на системах с systemd.

    [code]
    while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done[/code]
    но давно и поэтому почти неправда! :)

     
  • 1.127, Аноним (123), 14:42, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >сборка в GCC c включением опции "-fstack-clash-protection"

    А куда вы некрофилов дели? На этом месте должна была выскочить парочка с воплем, что на их куркуляторах это будет тормозить.

     
     
  • 2.136, Andrey Mitrofanov (?), 14:58, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>сборка в GCC c включением опции "-fstack-clash-protection"
    > А куда вы некрофилов дели? На этом месте должна была выскочить парочка
    > с воплем, что на их куркуляторах это будет тормозить.

    Все перековались уже.  Вкушають прогресс, только за ушами трещит.

     
  • 1.141, Аноним (141), 15:24, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    в systemd найдена уязвимость - инородное тело в виде ядра linux
     
  • 1.154, Баш Портянщик (?), 16:42, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >В systemd найдена уязвимость

    То ли ещё будет... Более кривого кода чем у сабжа вряд ли можно ещё где-то найти.

     
     
  • 2.155, Andrey Mitrofanov (?), 16:53, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Баш Портянщик пишет:

    [I]Бро![/I]

    >>В systemd найдена уязвимость
    > То ли ещё будет... Более кривого кода чем у сабжа вряд ли
    > можно ещё где-то найти.

    Да.  Только кривой код сам по себе не причина.  Причина в отсуствии архитектуры, шапкозакидательстве (pat intended tnx) апстрима и "неискренненьких" целях проекта.  Код хоть обисправляйся -- причины-то не изменятся.

     
     
  • 3.157, Аноним (-), 17:18, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Отсутствие архитектури и кривой код - это про sysvinit & bsd init. Натащить кучу баш-скриптов, которые в каждом дистрибутиве работают по-своему, а потом ждать при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками.
     
     
  • 4.158, Аноним (158), 17:21, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Единственный плюс этого подхода - можно даже не пытаться реализовывать надежно работающий hotplug.
     
     
  • 5.204, Аноним (28), 11:37, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы же в курсе что полная поддержка plug and play появилась в GNU/Linux раньше чем в Windows, для примера.
     
  • 4.168, анонн (?), 18:59, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > bsd init.
    > Натащить кучу баш-скриптов,
    > bsd
    > баш

    /0

    > Отсутствие архитектури и кривой код - это про sysvinit & bsd init

    Типа, слишком мало кода для серьезной системы инициализации, нужно хотя бы 400 000 строк?
    [code]
    % cloc /usr/src/sbin/init
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    C                                1            253            349           1457
    make                             1              5              3             24
    C/C++ Header                     1              2             36              7
    -------------------------------------------------------------------------------
    SUM:                             3            260            388           1488
    [/code]
    Или слишком понятный код, без кучи однобуквенных переменных и захардкоженых констант?
    [code]
    if (sp->se_type) {
      /* Don't use malloc after fork */
      strcpy(term, "TERM=");
      strlcat(term, sp->se_type, sizeof(term));
      env[0] = term;
      env[1] = NULL;
    }
    [/code]
    а нужно было

    https://github.com/systemd/systemd/blob/ad16158c10dfc3258831a9ff2f1a988214f516
    [code]
    ret = new(char, (e - slice) + 1 + strlen(name) + 6 + 1);
    ---
    strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e);
    --
    [/code]

     
     
  • 5.208, Аноним (28), 11:44, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Они не понимают о чём говорят и не разбираются, просто повторяют что им потеринг сказал, фанатики.
     
     
  • 6.284, Michael Shigorin (ok), 15:23, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > фанатики

    Горше всего, что не просто фанатики, а ещё и не лечатся...

    PS: в смысле картина маслом:

    - а ваши башпортянки!!!1  а наша системдешечка!!111
    - внутрь смотрел?
    - у вас никаких аргументов!
    - вот сюда конкретно смотрел?  с секундомером стоял?
    - ну вот, опять эти неосиляторы со своими абстрактными доводами!
    - *занавес*

     
  • 4.181, YetAnotherOnanym (ok), 01:10, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками

    Можете назвать дистр, в котором sysvinit при каждой загрузке сыпался с нечитаемыми ошибками? И что Вы определяете как "нечитаемость"?

     
  • 4.196, Адекват (ok), 09:25, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >а потом ждать при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками.

    Вы или троль или неуч. Когда я пользовался арчем с его bsd-like-init никаких 5 минут не было, на простом hdd-sata2 загрузка может минуту занимала, причем это от груба до полной готовности десктопа. Даже тогда в /etc/rc.conf была возможность указать запускать демон в бекграунд, или запретит загрузку или указать порядок загрузки демонов. Все в одном файле, а не в непойми-каких-каталогах-которые-я-забуду-где-находятся.
    Если ошибки были - они были вполне читаемы, потому, что не было никаких заставок, а где заставки были, их можно было отключить и почитать как проходит загрузка. Тогда все было лучше, но вы же не поверите, сейчас xfce4 на ssd загружается дольше, чем xfce4 в 2008 году на sata2-hdd.

     
     
     
    Часть нити удалена модератором

  • 6.209, Аноним (28), 11:46, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет не знаете, ничто не мешает вам поставить тот дистрибутив и убедиться.
     
     
  • 7.212, Аноним (-), 11:51, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    # systemd-analyze
    Startup finished in 3.528s (kernel) + 42.502s (userspace) = 46.031s
     
     
  • 8.214, Аноним (28), 11:54, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И как это опровергает быструю загрузку на sysvinit?
     
     
  • 9.216, Аноним (-), 11:56, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это опровергает фантазии о медленной загрузке в systemd.
     
     
  • 10.231, Аноним (28), 12:21, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще то нет
     
     
  • 11.276, Аноним (276), 00:44, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    root ThinkPad-R51 systemd-analyze Startup finished in 8 617s kernel 46 5... текст скрыт, показать
     
     
  • 12.279, анонн (?), 13:19, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > root@ThinkPad-R51:~# systemd-analyze
    > Startup finished in 8.617s (kernel) + 46.529s (userspace) = 55.146s
    > graphical.target reached after 46.491s in userspace

    Круто! Правда, у мня примерно столько же (меньше минуты) когда-то "изкоробочный бсдинит" с убогого 1.8" харда грузился.

    > root@ThinkPad-R51:~# cat /proc/cpuinfo
    > 100500 ненужных деталей, вместо пары характеристик загрузочного диска
    > root@ThinkPad-R51:~#

     
     
  • 13.281, Аноним (276), 14:14, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    root ThinkPad-R51 hdparm -I dev sda dev sda ATA device, with non-removable... текст скрыт, показать
     
  • 10.285, Michael Shigorin (ok), 15:31, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Это опровергает фантазии о медленной загрузке в systemd.

    А вот была статья о том, как ребята задались загрузить eeePC (это ещё _совсем_ дохлый атом) за пять секунд.  Да, с его чахлым SSD.  Нет, никакими systemd не воняло ещё, хотя ещё вменяемый Леннарт уже дотянулся до udev.

    https://lwn.net/Articles/299483/

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

     
     
  • 11.287, Аноним (287), 16:18, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот EeePC c Xubuntu 18.04. И это время загрузки в графическое окружение, а не в командную строку.

    root@EeePC-901:~# systemd-analyze
    Startup finished in 5.463s (kernel) + 21.878s (userspace) = 27.341s
    graphical.target reached after 21.831s in userspace

    root@EeePC-901:~# hdparm -I /dev/sda

    /dev/sda:

    CompactFlash ATA device
    Model Number:       ASUS-PHISON SSD                        
    Serial Number:      SOQ1782276          
    Firmware Revision:  TST2.04U
    ...
    root@EeePC-901:~# hdparm -I /dev/sdb

    /dev/sdb:

    CompactFlash ATA device
    Model Number:       ASUS-PHISON SSD                        
    Serial Number:      SOQ2780070          
    Firmware Revision:  TST2.04P
    ...

    root@EeePC-901:~# dmidecode -t2
    # dmidecode 3.1
    Getting SMBIOS data from sysfs.
    SMBIOS 2.5 present.

    Handle 0x0002, DMI type 2, 15 bytes
    Base Board Information
    Manufacturer: ASUSTeK Computer INC.
    Product Name: 901
    ...

     
     
  • 12.291, Аноним (-), 18:03, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > The superfast (and furious) systemD
    > Startup finished in 5.463s (kernel) + 21.878s (userspace) = 27.341s

    https://lwn.net/Articles/299483/
    > 2008
    > At the Linux Plumbers Conference Thursday, Arjan van de Ven, Linux developer at Intel and author of PowerTOP, and Auke Kok, another Linux developer at Intel's Open Source Technology Center, demonstrated a Linux system booting in five seconds. The hardware was an Asus EEE PC, which has solid-state storage, and the two developers beat the five second mark with two software loads: one modified Fedora and one modified Moblin
    > booting in five seconds
    > 21.878s (userspace)

    Эпичненько ))

     
     
  • 13.294, Аноним (-), 19:39, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Эпичненько что Ubuntu из 2019-го года с дьявольским systemd грузится 27 секунд, а Fedora из 2008-го c божественным System V Init — 45 секунд на одинаковом железе.
     
     
  • 14.295, Аноним (295), 19:58, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Эпичненько что Ubuntu из 2019-го года с дьявольским systemd грузится 27 секунд,

    Эпичненько, что читать сестемдатнутные умеют очень уж выборочно.
    > а Fedora из 2008-го c божественным System V Init — 45 секунд на одинаковом железе.

    «It spends 12 seconds running modprobe running a shell running modprobe, which ends up loading a single module»

    Ну и ловко проигнорированное
    > booting in five seconds

     
     
  • 15.297, Аноним (297), 20:33, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > «It spends 12 seconds running modprobe running a shell running modprobe, which
    > ends up loading a single module»

    Ты ещё не понял, что это и есть вся суть sysvinit/bsdinit/openrc с костылями вроде rc и прочими парсерами скриптопортянок?

    >> Ну и ловко проигнорированное
    > booting in five seconds

    Лови: https://www.youtube.com/watch?v=M6e-ANgye30

     
     
  • 16.298, Michael Shigorin (ok), 20:48, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты ещё не понял, что это и есть вся суть sysvinit/bsdinit/openrc
    > с костылями вроде rc и прочими парсерами скриптопортянок?

    О-оо, кто-то напарывается на ответ Линуса насчёт "кому грузить модули".  Причём так и не оценив иронии момента.

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

     
  • 16.306, анонн (?), 21:57, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> ends up loading a single module»
    > Ты ещё не понял, что это и есть вся суть sysvinit/bsdinit/openrc с
    > костылями вроде rc и прочими парсерами скриптопортянок?

    Притягивание за уши, лвл 80?

    >>> Ну и ловко проигнорированное
    >> booting in five seconds
    > Лови: https://www.youtube.com/watch?v=M6e-ANgye30

    И? 8 минут любоваться на поттеринга  желания нет.
    Или это был намек на
    > 2013, 5s Boot Delivered

    Так то похоже было из разряда "обещать - не значит жениться", иначе тут бы не хвастались  
    > # systemd-analyze
    > Startup finished in 3.528s (kernel) + 42.502s (userspace) = 46.031s
    > root@ThinkPad-R51:~# systemd-analyze
    > Startup finished in 8.617s (kernel) + 46.529s (userspace) = 55.146s

    Кстати, о скорости загрузки в более современных (2017) условиях и реалиях, ловите:
    www.youtube.com/watch?v=hx30Z7_G-vk
    Естественно, НеСистемД с треском проиграл, заняв предпоследнее место! ))

     
  • 12.296, Аноним (287), 20:13, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати, я не выключал никакие сервисы root EeePC-901 systemctl list-unit-fil... текст скрыт, показать
     
     
  • 13.301, анонн (?), 21:23, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, я не выключал никакие сервисы:

    Отгововрки, честно сказать, никому не интересны.
    > И большую часть времени загрузки занимает подключение к Wi-Fi сети:

    О-отличная демонастрация качества распараллеливания загрузки! Благодарю.

     
     
  • 14.307, Andrey Mitrofanov (?), 10:17, 22/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Кстати, я не выключал никакие сервисы:
    > Отгововрки, честно сказать, никому не интересны.
    >> И большую часть времени загрузки занимает подключение к Wi-Fi сети:
    > О-отличная демонастрация качества распараллеливания загрузки! Благодарю.

    +1
    https://www.anekdot.ru/id/-40121022/ Ачивмент опенед!

    //https://duckduckgo.com/?q=Windows+95+%D0%B7%D0%B0%D0&

     
  • 4.202, Аноним (28), 11:35, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > баш-скриптов, которые в каждом дистрибутиве работают по-своему

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

     
     
  • 5.207, Аноним (-), 11:42, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если ты пишешь софтину с демоном (тем более с таким, который зависит от других), тебе придется писать свои init-скрипты под каждый дистрибутив, либо ей никто не сможет пользоваться.
     
     
  • 6.211, Аноним (28), 11:50, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Инит срипты пишут разработчики дистрибутива, под свой дистрибутив сами.
     
     
  • 7.219, Аноним (-), 12:01, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    O RLY? И когда же это они их напишут?
     
     
  • 8.221, Аноним (28), 12:05, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А когда пакет будут делать, тогда и напишут, по стандартам своего дистрибутива.
     
     
  • 9.223, Аноним (-), 12:09, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То есть через несколько лет в лучшем случае.
     
     
  • 10.230, Аноним (28), 12:18, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если нужных зависимостей в дистрибутиве нет то возможно и дольше. Unit файл тут ничем не поможет.
     
     
  • 11.234, Аноним (-), 12:29, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А не надо придумывать, что нужных зависимостей нет.
     
     
  • 12.241, Аноним (28), 12:44, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А не надо придумывать, что нужных зависимостей нет.

    Так это автор исходного сообщения написал: «Если ты пишешь софтину с демоном (тем более с таким, который зависит от других)»

    С чего он взял что они есть в том дистрибутиве?

     
     
  • 13.243, Аноним (243), 13:02, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ещё раз для невменяемых: нужные зависимости есть. Это дано. Но с sysvinit/bsdinit жизнь от этого не сильно упрощается.
     
     
  • 14.264, Аноним (264), 19:27, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Аргументы кончились, пошли попытки оскорбления? :-)

    А откуда взялись эти зависимости? Кто сделал пакет для них для _этого конкретного_ дистрибутива? Кто их поставил на хост?

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

     
  • 6.213, Аноним (28), 11:53, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А unit файлы не надо писать под каждый дистрибутив? У разных дистрибутивов разные зависимости и расположение каталогов например.
     
     
  • 7.217, Аноним (-), 12:00, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Каталоги тут вообще при чём? И да, в systemd всё стандартизовано и мне ещё ни разу не приходилось писать разные unitы (но даже если и пришлось бы - это было бы гораздо легче из-за их декларативной природы и маленького размера).
     
     
  • 8.220, Аноним (28), 12:04, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В каталогах лежат запускаемые файлы и каталоги передаются аргументами и параметрами запускаемым демонам, скрипты тоже маленького размера и стандартной структуры.
     
     
  • 9.222, Аноним (-), 12:08, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Понятно, очередной покусанный bsdinit.
     
     
  • 10.225, Аноним (28), 12:11, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нечего возразить? :-)
     
  • 10.227, Аноним (28), 12:12, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если нечего возразить то просто промолчи, не обязательно пытаться писать оскорбления :-)
     
  • 10.265, Аноним (264), 19:30, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Задание на дом, возьмите unit файл из redhat и попробуйте запустить его в debian, например:
    https://git.postgresql.org/gitweb/?p=pgrpms.git;a=blob;f=rpm/redhat/11/postgre

    подсказка: в debian нет каталога /var/lib/pgsql

     
     
  • 11.290, Аноним (-), 17:04, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И дальше что? Это не "unit файл из redhat", а unit из Postgres ДЛЯ Red Hat. Ключевое слово - из Postgres. То есть сервис пишут разработчики приложения, а уж как - это другой вопрос.
     
     
  • 12.292, Совершенно другой аноним (?), 18:24, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Раньше было несколько подходов к инициализации - sysv style - bsd style я так п... текст скрыт, показать
     
  • 12.293, Совершенно другой аноним (?), 18:40, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати, для FreeBSD, судя по статье (https://postgrespro.ru/docs/postgresql/10/server-start.html), тоже был свой скрипт и тоже от разработчиков Postgres.


     
  • 4.206, Аноним (28), 11:40, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а потом ждать при каждой загрузке по 5 минут когда всё это посыпется с нечитаемыми ошибками.

    Если дистрибутив которым вы пользовались был сделан плохо, то чем вам тут поможет systemd? Авторы плохого дистрибутива и unit файлы напишут плохо, в чём разница?

     
     
  • 5.210, Аноним (-), 11:48, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дистрибутв тут ни при чем. sysvinit и bsdinit в принципе не умеют в зависимости. В sysvinit они сбоку как костыль, в bsdinit всё просто прибито гвоздями, но это тоже не помогает.
     
     
  • 6.215, Аноним (28), 11:56, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и что?
     
  • 6.218, Аноним (28), 12:00, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В docker systemd не нужен, в kubernetes тоже, сервер в стойке никто каждый день не перезагружает, для чего вам это всё, systemd для гуголь ноута?
     
  • 6.253, анонн (?), 15:50, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О, сколько вам открытий чудных code head etc rc d local_unbound ... текст скрыт, показать
     
     
  • 7.254, анонн (?), 15:52, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Первую строчку съело при копипасте:

    > [code]
    > % echo '#!/bin/sh
    > #
    > # $FreeBSD$
    > #
    > # PROVIDE: local_anon
    > # REQUIRE: FILESYSTEMS local_unbound' > /tmp/local_anon

    % rcorder /etc/rc.d/* local_anon|grep -B 4 local_anon
    > /etc/rc.d/devd
    > /etc/rc.d/netwait
    > /etc/rc.d/defaultroute
    > /etc/rc.d/local_unbound
    > /tmp/local_anon
    > [/code]

     
  • 7.277, Аноним (-), 10:22, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "Ах, посмотрите на мои костыли! Разве они не прекрасны?"
     
  • 7.280, Аноним (-), 13:24, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Костыль к init под названием rc умеет парсить костыльные комментарии в шелл-портянках. Не это ли верх архитектурного изящества?

    ЗЫ в sysvinit такие костыли тоже любят

     
     
  • 8.282, анонн (?), 14:27, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Костыль к init под названием rc умеет парсить костыльные комментарии в шелл-портянках.

    То ли дело некостыльные, модные и молодежные юниты!

    [code]
    [Unit]
    Description=Service B
    Requires=a.service
    After=a.service[/code]
    Правда, у меня для вас плохие новости:
    У вашего костыля к инит на 400 000 строк кода все то же самое:

    https://github.com/systemd/systemd/search?q=UnitDependencytype=
    только парсинг раскидан еще и по 100500 местам
    https://github.com/systemd/systemd/search?l=C&q="Wants="&type=
    наверное, чтобы желающим что-то поправить не сильно скучно было.

    > Не это ли верх архитектурного изящества?

    То ли дело системда -- главное в сам код не заглядывать, а то про «изящество на архитектурном уровне» аж легенды ходят.

     
     
  • 9.299, Michael Shigorin (ok), 20:52, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не это ли верх архитектурного изящества?
    > То ли дело системда -- главное в сам код не заглядывать, а
    > то про «изящество на архитектурном уровне» аж легенды ходят.

    Думаете, допрёт?  Мне всё больше кажется, что он невменяем -- именно в том плане, что не воспринимает фактические аргументы, а пытается изо всех сил искать и приводить "удобные".

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

    А невменяемый -- пустая трата времени.  Причём наверняка что сообщества, что общества, что родителей... :(

     
     
  • 10.303, анонн (?), 21:35, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Думаете, допрёт?  Мне всё больше кажется, что он невменяем -- именно
    > в том плане, что не воспринимает фактические аргументы, а пытается изо
    > всех сил искать и приводить "удобные".

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

    > С вменяемым человеком можно прийти с разных позиций, обсудить, поспорить даже

    Диалог с вменяемым человеком вообще редко начинается с довольно категоричных и провокативных утверждений (см #210) ;)

     
     ....нить скрыта, показать (60)

  • 1.170, Нанобот (ok), 19:20, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >так как в ходе атаки обращение производится к неотражённым страницам памяти (unmapped), ядро не может вызвать данный обработчик сигнала

    что за волшебные такие страницы, из-за которых сигнал не вызывается?
    я конечно понимаю, что фактчекинг нынче не в моде, но...[code]signal(SIGSEGV, my_handler);
    *((int*)(0x44444444)) = 0x44444444;[/code] приводит к успешному вызову обработчика

     
     
  • 2.191, Аноним (1), 06:58, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    signal(SIGSEGV, (__sighandler_t)0xdeadbeef);
     
     
  • 3.192, Аноним (1), 07:01, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пример некорректен, дан для простоты наглядности. Хендлеру для работы нужен стек.
     
     
  • 4.235, Нанобот (ok), 12:29, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пример некорректен, дан для простоты наглядности. Хендлеру для работы нужен стек.

    да, действительно, там же стек переполнен...
    ...просто в новости оно как-то мутно описано

     
     
  • 5.239, Аноним (28), 12:36, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    http://man7.org/linux/man-pages/man2/sigaltstack.2.html

    The most common usage of an alternate signal stack is to handle the SIGSEGV signal

     
  • 1.171, 111 (??), 19:47, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    опять портянки оказались безопаснее и комфортнее... да еще и быстрее компутер загружают...
     
     
  • 2.205, Аноним (-), 11:39, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прогресс вообще зло. В пещерах и на деревьях было лучше.
     
     
  • 3.224, Аноним (28), 12:09, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Неправда, systemd это не прогресс,с чего вы взяли что любое изменение это всегда прогресс?
     
     
  • 4.226, Аноним (-), 12:12, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не я решил, а подавляющее большинство дистрибутивов. Все основные во всяком случае.
     
     
  • 5.233, Аноним (28), 12:26, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Это не я решил, а подавляющее большинство дистрибутивов. Все основные во всяком
    > случае.

    Он такого не решали.

     
     
  • 6.236, Аноним (-), 12:31, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://en.wikipedia.org/wiki/Systemd#Adoption
     
     
  • 7.240, Аноним (28), 12:40, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > https://en.wikipedia.org/wiki/Systemd#Adoption

    Процитируйте пожалуйста где там написано что «большинство дистрибутивов решило что systemd это прогресс».

     
     
  • 8.244, Аноним (243), 13:10, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Оно не само решило, его ZOG заставило перейти на systemd?
     
     
  • 9.272, Michael Shigorin (ok), 20:36, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно не само решило, его ZOG заставило перейти на systemd?

    Гругря, да -- уж не знаю, что тут будет за Z и O, а G в данном случае -- чётко GNOME3.

    Говорю же, марш учить матчасть, школодранцы.

     
  • 8.245, Andrey Mitrofanov (?), 13:17, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> https://en.wikipedia.org/wiki/Systemd#Adoption
    > Процитируйте пожалуйста где там написано что «большинство дистрибутивов решило что
    > systemd это прогресс».

    Война - это мир, черное - это белое, ад-опшон - это "прогресс", доля "рынка" - это "успех"...

    Новояз этих, как их...  ну, с мозгом работающим в направлении, кому б продаться.
    https://www.opennet.ru/openforum/vsluhforumID3/116553.html#57

    Иного они не разумеют -- аксиоматика не та, самосознание не ... ну, тоже чего-то "не".

    Поэтому Главный Аргумент -- просто повторять требуемый вывод.

    Н - Настойчивость.  У - Уверенность.  Р - Руки порежет.

     
  • 3.228, Andrey Mitrofanov (?), 12:12, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Прогресс вообще зло. В пещерах и на деревьях было лучше.

    Прогресс "вообще" -- не доказано, и, типа, не об этом речь.

    Не надо кривых обощений и спрыг-спрыгов.

    "Прогресс" _в s-d_  -  да, зло.

    Прололжайте прыгать по расчёске.

     
  • 1.174, Аноним (174), 21:51, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Бугага таки нашли, не прошло и трех лет.
    На самом деле там еще 14 подобных
    NOTABUG! сопсобных уложить и pid 1 и ядро за одно.
     
  • 1.176, Аноним (176), 23:45, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Тут в обсуждениях мелькало, что вот systemd пытается сделать в линуксе как в винде, в одном комментарии даже говорится, что, цитата: "линуксу не достаёт функций которые были еще в NT4".

    Кто-нибудь может объяснить, что за функции такие в винда вообще и нт4 в частности. Мб дилетантский вопрос, но мне не понятно, вроде в линуксе всё для жизни есть, всё примерно то же самое, что и в винде, можно делать. Каких же там функций нет на уровне базовой системы?

     
     
  • 2.177, 111 (??), 23:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Каких же там функций нет на уровне базовой системы?

    Божественности! Давно известно, что в Виндовс - иконы и службы, а в Линуксе - демоны и зомби...

     
     
  • 3.178, Аноним (176), 23:54, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В винде зомби тоже есть
     
     
  • 4.251, Аноним (251), 15:14, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В винде зомби тоже есть

    Ну да, только там они за монитором сидят

     
  • 2.203, Аноним (-), 11:37, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Даже не как в винде, а как в макоси и лучше. Функции эти - зависимости между сервисами, запуск сервисов по событиям (например вставили USB-аудиокарту - запустился PulseAudio), параллельный запуск сервисов, контроль состояния сервисов и перезапуск их при необходимости (с правильным разрешением зависимостей), пользовательские сервисы и другое.
     
     
  • 3.238, Аноним (28), 12:33, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Даже не как в винде, а как в макоси и лучше. Функции
    > эти - зависимости между сервисами, запуск сервисов по событиям (например вставили
    > USB-аудиокарту - запустился PulseAudio), параллельный запуск сервисов, контроль состояния
    > сервисов и перезапуск их при необходимости (с правильным разрешением зависимостей), пользовательские
    > сервисы и другое.

    На сервере в стойке это всё не нужно.

     
     
  • 4.242, Аноним (243), 12:56, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там не нужно правильно перезапустить сервис если он упадёт? O RLY? Ну тогда тебе и электричество не нужно - обойдешься лучиной.
     
     
  • 5.267, Аноним (264), 19:49, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы без балансировщика работаете, без резервных серверов?
     
  • 3.248, Аноним (176), 14:06, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Неужели в sysvinit linux нельзя никак было запустить сервис по событию, вставленной флешке например?
     
  • 3.255, анонн (?), 16:21, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    code more etc devd conf 124 grep service -B4 notify 0 match system IF... текст скрыт, показать
     
     
  • 4.257, Аноним (257), 17:09, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > devd

    А теперь вот это недоudev выкини и всё то же самое - на чистом bsd init.

     
     
  • 5.260, анонн (?), 18:11, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> devd
    > А теперь вот это недоudev выкини

    "Недо" оно потому что туда не встроили dbus и еще 100500 свистелок или потому что не прибили полуметровыми гвоздями?

    > и всё то же самое -  на чистом bsd init.

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

     
     
  • 6.261, Аноним (261), 18:32, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Свистелка это твоя devd. 4.4BSD прекрасно жила без неё. Если ты не понимаешь зачем нужны зависимости между сервисами, API и взаимодействие device fs с init, просто проходи мимо.
     
     
  • 7.262, анонн (?), 18:43, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Свистелка это твоя devd. 4.4BSD прекрасно жила без неё.

    Тоесть, возразить что-то по теме нечего?
    > Если ты не понимаешь зачем нужны зависимости между сервисами,

    О, еще один рассказчик про отсутствие зависимостей в несистемде?

     
  • 7.268, Аноним (264), 19:53, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем оно нужно? Расскажите, можно на примере.
     
  • 2.237, Аноним (28), 12:31, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Автоматический перезапуск упавшего сервиса, программный сишный API для регистрации сервиса в системе. Программный сишный API для чтения событий из системных журналов.
     
     
  • 3.246, Andrey Mitrofanov (?), 13:21, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Автоматический перезапуск упавшего сервиса,

    Не было такого в NT4.  ...или я точно в склерозе?

     
     
  • 4.269, Аноним (264), 20:04, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Service Control Manager в NT 4 был https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0980

    скорее всего у него уже и параметр "автоперезапуск" был.

     
     
  • 5.278, Andrey Mitrofanov (?), 10:54, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > скорее всего у него уже и параметр "автоперезапуск" был.[I]
    > скорее всего

    [/I]Чё-т ты не убедил моего склерза.  Автозапуск был - при загрузку системы чтоб.
    А вот Авто-пере-, "перезапуск упавшего", вело-мото-фото...
    ...не припоминаю.   [I]Вы фсйо врёти.

     
  • 3.249, Аноним (176), 14:07, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И в sysvinit нельзя было читать системный журнал??
     
     
  • 4.270, Аноним (264), 20:06, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно конечно, просто самому придётся писать разделение записей на поля и поиск с фильтрацией по источнику события.
     
  • 1.188, Александр Владимирович (ok), 06:21, 20/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Systemd начал разрабатываться практически сразу после того, как в совете директоров RedHat появились армейские генералы. Вполне логично рассматривать подобные "уязвимости" как прямое предназначение systemd. В нужный момент вызвать сбои в инфраструктуре вероятного противника - вполне себе привлекательное вложение для средств из оборонного бюджета США. Не вызывает удивления и то, что IBM, компания, которая практически с самого начала своего существования работала в тесной связи с военными разработками, вдруг решила приобрести RedHat...
     
     
  • 2.198, Аноним (1), 09:59, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Флот --> торпеды --> кибернетика --> ИБМ.

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

     
  • 2.289, Аноним (289), 16:53, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Он же троллей нанял что системд на опеннете защищали.
     
  • 1.252, Аноним (252), 15:34, 20/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ох, пионерство. Пусть забавляются, короче. А мы подождём rust'овцев с redux'ом и прочими нескучностями.
     
     
  • 2.256, Аноним (257), 17:04, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Подождёте пару тысяч лет.
     
     
  • 3.259, пох (?), 17:31, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну что ты, что ты - они быстрые. Или ты имел в виду - работающего, а не "компилируется же ж"?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


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