эта музыка будет вечной

[stas]

TIL another Java WTF: you can not interrupt regex matches. I mean you can try, but it would just ignore that. So for any Java service that has regex matching and timeouts, that's DoS-in-a-box. 

Comments

[sab123]

Не очень понятно, как их предполагается "прерывать" кроме как убить тред. Да и никто нигде их как-то особо не прерывает.

[stas]

В Жабе для этого существует InterruptedException вроде. Проблема что есть функция с непредсказуемым временем выполнения и без возможности его ограничить.

[straktor]

предсказуемое время выполнения даёт только реалтайм ос с реалтайм джавой и хорошим дизайном

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

если вам нужно, то форкните апачевские, да и сановскую никто не запрещал копипастить

InterruptedException, Thread.interrupt -- это всё хинты, которые надо руками проверять

[stas]

предсказуемое время выполнения даёт только реалтайм ос с реалтайм джавой

Эээ, вы как-то совсем не в ту степь поехали.

считается, что девелопер понимает и может писать норм. линейный паттерн

Кем считается? Вы вообще поняли, о чём речь идёт, или чисто по ключевым словам реагируете?

если вам нужно, то форкните апачевские, да и сановскую никто не запрещал копипастить

Это вы о чём?

[straktor]

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

вы написали про регэкспы "функция с непредсказуемым временем выполнения и без возможности его ограничить"

это чушь, потому что у регэкспов время выполнения предсказуемое, да, экспоненциальное, и нет, даже сортировку (qsort может выродиться в O(n^2) при специально неудачном подборе данных, "непредсказуемо" в вашем лексиконе) нельзя в библиотеке любого языка прервать

>> если вам нужно, то форкните апачевские, да и сановскую никто не запрещал копипастить
> Это вы о чём?

про библиотеки регэкспов
самые распространённые - встроенная java.util.regex и jakarta.apache.org/regexp/
исходники есть, если надо -- вставьте проверку на интеррапт

[stas]

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

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

нельзя в библиотеке любого языка прервать

Это, мягко говоря, не так.

исходники есть, если надо -- вставьте проверку на интеррапт

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

[ygam]

Switch to .Net: https://msdn.microsoft.com/en-us/library/hh160210(v=vs.110).aspx

[stas]

:))

[leo_sosnine]

а Вы на джаве пишете?

[stas]

Иногда приходится.

[sab123]

Кстати, в сервисах обычно имеет смысл устраивать ограничение ресурсов на весь запрос. Оно решит проблемы и с парсингом XML, и со всем остальным.

[stas]

А чем весь запрос поможет? В контексте всего запроса java.util.regex точно так же будет бесконечно тупить, как и в любом другом контексте.

[sab123]

Тем, что запрос - единица работы. Имеет смысл ограничивать по ресурсам весь запрос, а не индивидуальные части.

[stas]

Отличный совет, но непонятно, какое отношение он имеет к обсуждаемой теме.

[sab123]

Нет смысла вставлять ограничения в конкретные вызовы API. Есть смысл делать ограничения на уровне единиц работы, а уж какие API там вызываются в процессе работы - неважно (но не знаю, есть ли такие ограничения в Джаве).

[stas]

Беда в том, что это ограничение невозможно сделать правильно в жабе. Т.е. правильный метод - это Thread.interrupt(), а Match.find() его игнорирует. Тем самым делая невозможным прервать нить, в которой тупит регексп. Можно, конечно, делать Thread.stop(), но это крайне не рекомендуется, см. напр.: https://stackoverflow.com/a/16504159/214196

[sab123]

Правильная единица - скорее не тред а, ClassLoader или как-то в этом роде, которая создает виртуальную под-машину со своим контекстом. Казалось бы, сборка мусора как раз позволяет все аккуратно позакрывать. Но на самом деле, конечно, наверное никто ничего такого не делает.

[stas]

Сборки мусора недостаточно, и в общем факт тот, что это так не работает, Thread.stop опасен, а рекомендуемое решение, которым все и пользуются - Thread.interrupt. Которое обычно работает, но как опять обычно же в жабе, кое-что они забыли.

[sab123]

Если его собирать сразу, а не неизвестно когда, и честно chfpe запускать finalizers - еще как достаточно. Ну можно еще исключение бросить чтоб оно раскрутило все блоки finally.

[stas]

Ну можно еще исключение бросить чтоб оно раскрутило все блоки finally.

О!. Проблема в том, что исключение нельзя бросить, когда оно внутри кода на C, имплементирующего java.util.regex.

[sab123]

Таки да, управление памятью в нативном коде - это проблема для такого решения. В-общем, как ни гляди, а такие вещи надо засовывать в отдельный процесс, что мне и пришло недавно в голову: http://babkin-cep.blogspot.com/2017/03/os-support-for-thread-stopping.html

И в общем и целом оно нынче недорого, особенно по сравнению с выполнением байткода.

[juan_gandhi]

Ну ни хуя себе сюрпризы.

Когда-то меня в Гугле ругали, что я слишком долгий регекс написал для ловли емейл-адресов в чате. Ну типа, хоть и правильно, да медленно; давай неправильно, но быстро.

[stas]

Тут же ещё такая штука, что по регекспу сразу не узнаешь, насколько он плох, а никаких способов ограничить (ну, кроме хаков с interruptibleSequence и т.п.) нет.

[juan_gandhi]

Да, в общем, interruptible, действительно, как-то решает эти жуткие вопросы.

[stas]

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

[juan_gandhi]

Кстати да, наверно. Вообще интересная тема. Тьюринг тут уже где-то рядом. Busy Beaver machine.

[alexcohn.livejournal.com]

Интересный вектор для DOS атаки