ISPmanager: срыв стэка. Еще один сюрприз от ISP?

"Доктор - я всегда ковырял гвоздем в ухе. А вот сегодня проколол. Почему так?"

Ну а вообще что-то менялось? Нагрузка? ISP обновляли? Может вообще filemgr был отключен, если такое возможно?

Нет. Это просто фатальная ошибка - связанная либо с некоректной работой аппаратного обеспечения либо кода операционной системы.

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

Ага - он сам с треском падает.

Форк бомбы не работают у любого мало-мальски приличного хостера. Это что-то совсем бородатое.

Т.е. конкретных примеров атаки, которая гарантированно не работает на 2.6.35, но работает скажем на 2.6.26 (это debian stable) - Вы привести не можете?

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

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

Панель на C++ написана. Все знает )))

Раз в жизни из-за бага, который будет закрыт. А не каждый день от нагрузки. Это разные вещи.

Да ладно? На каждом втором хостинге какой-нибудь сайт выжрет все ресурсы памяти. Это не форк, но результат тот же. Ну а кроме того, не работает вариант, когда занимают все процессорное время и весь ввод-вывод. Вдарьте бенчмарком по диску из мускула - сервер не чихнет даже. Опять же BurnMMX. Кроме FastVPS и Host Low Cost больше нет ни одного хостинга, кто его выдержит. Ткните пальцем на любой из них, дайте полноценный шелл с этой командой и я положу сервак.

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

Конерктеный пример атаки: brunMMX. Тестируйте, скоро как раз выходные, будет чем заняться. ))))

А есть технические проблемы там это сделать?

Просто не называйте первый попавшийся сервер с установленной панелькой ispmanager/plesk/whatever "хостингом" - и их число упадет на много порядков. Боюсь, единицы из этих "хостеров" хоть что-то вообще знают про возможности ОС по ограничению пользователей.

А картинка прежняя?

Ну сталбыть Вы не знаете. Ни C++ ни принципов работы программ в linux.

А я просто не называю хостингами эти "каждые вторые". Вот и все. Хостинговых компаний на самом деле - десятка два-три в России. О форк-бомбах там забыли поди лет десять назад, когда большинство этих хостингов и появилось ;-)

И что надо сделать чтобы оно у меня заработало?

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

Да? Вы правда считаете, что возможночти C++ сопоставимы с PHP? Поверьте, C++ может многое.

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

Место в памяти виновника:

ffffffff81144ddf

И ниже видно кому оно принадлежало:

bh_log_doit.

Он может то, что в линукс не может ЛЮБАЯ программа, написанная на ЛЮБОМ языке программирования?

Это баг ядра. Проблемой является не приложение, а этот самый баг. Раз нашли способ воспроизвести проблему - по идее можно было бы на тестовой машинке оформить все что нужно для нормального багрепорта на @kernel.org.

Ну, например, попробуйте поиграться с указателями памяти в Java. Не уверен, что у Вас что-то получится. А эти положить сервер элементарно. В C++ можно руками их задавать.

Это не баг ядра. Это баг бэкапной системы, частично внедренной в ядро.

И что, это вызовет kernel panic?

Ну, если код работает в пространстве ядра - это баг ядра, верно? А уж сторонний это модуль или из vanila - Вам виднее, мы ж тут не телепаты совсем ;-)

Да. Неаккуратная работа с указателями в C++ вызовет панику ядра. В Java так накосячить не получится. Только если специально и то тяжело. C++ крайне гибкая штука, но если не уметь им пользоваться, то он в мясорубку сервер превратить может.

Данная проблема, как выяснилось была именно в кривом коде C++. Как видите свалил сервер.

Вот мой коллега нашел строчку:

strncat(all_path, "/", sizeof("/"));

Объединили два стринга. Только длина второго была не количество символов, а количество байт, которое занимает "/", а это больше. Образовался пустой участок памяти, который вышел за обозначенные пределы и вот Вам пожалуйста, kernel panic вызванный кодом C++.

Ну так то да, но ядра не kernel.org )))) С Кернела скачали хорошее ядро, а испортили его уже потом. Нечего им багрепортить. Самим исправлять надо.

Открытым остался только вопрос, почему именно ISP попался на это.

Забавно обвинять ISPmanager в ошибке собственнопатченного ядра.

Boris A Dolgov добавил 27.01.2011 в 00:48

Нет, этого никогда не бывает и не может быть. Иначе я бы уронил любой сервер программой *((int*)0)=0; Работа с указателями в юзерспейсе вызовет сегфолт или даже сигбас, но никогда не панику. Панику вызовет работа с указателями в ядре.