kish4ever May 26 2020 at 21:47

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

16 min

4.4K

Oracle*Java**nix*C*Development Management*

Comments 11

xtender May 27 2020 at 00:34

А почему не просто установить параметр fixed_date?
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/FIXED_DATE.html#GUID-2AE0D45E-C4EB-4A12-87F0-69F7CFF1CB30

kish4ever May 27 2020 at 07:20

Cпасибо за интересную идею. Ее как оказалось мы не смотрели при отборе вариантов. Но тут есть момент: время то полностью заморозится в таком случае. А нам нужно чтобы оно продолжало тикать и после модификации.

xtender May 27 2020 at 00:36

Вообще обычно правильнее использовать в своём коде свою кастомную функцию вместо sysdate/current_xxx. Это наиболее распространённый, простой и гибкий подход.

kish4ever May 27 2020 at 08:03

Пфф, как не красиво. Зачем делать для прода кастомную функцию, которая заменяет собой системные функции (и при этом на проде время не нужно менять)?
Если переписывать вообще все что есть на тестовой среде под такие требования — код будет от прода отличаться. К тому же никто не сможет запретить написать код без использования кастом функции для времени. Спасибо, но нет.

gecube May 27 2020 at 11:12

Я себе это вижу немного по-другому. Везде в коде использовать кастомную функцию. А вот на тесте — внутри нее идет переопределение даты. А на проде она дальше каскадно вызывает системную функцию. Проблема в том, что каждую функцию, которую нужно переопределить, придется оформить таким образом. И не дай Бог случайно воспользоваться штатными функциями работы с датой. По сути — изобретаем свой язык поверх стандартного языка ) Можно? Можно. Сложно? Да.

kish4ever May 27 2020 at 17:03

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

xtender May 27 2020 at 13:12

Вы работаете только с локальным каким-то бизнесом без интернализации и сложных финансовых проводок? Дело в том, что sysdate/systimestamp — не бизнесовые даты. На самом деле, очень много различных тонкостей бывает, начиная со смены таймзоны (летнее/зимнее/отмена летнего/миграция/расширение в другой регион и тд) и заканчивая отложенных или будущих операций. Sysdate/systimestamp пойдут для обычного логгинга или другого не особенно завязанного на время функционала, но не для бизнес операций, как например, тот же опердень в банкинге. Своя кастомная функция позволяет это все строго формализовать в одном месте.

kish4ever May 27 2020 at 16:58

Верно, локальный бизнес в России, но в разных городах и разных часовых поясах.
И меняли таймзоны на своих серверах и не раз, скажем спасибо нашему правительству
Для отложенных операций в будущем мы у себя используем current_date и нам вполне этого хватает, хотя конечно соглашусь что в других случаях этого могло быть недостаточно

gecube May 27 2020 at 01:34

Очень интересный и полезный опыт!

Но хочу уточнить:

были проверены системы легкой виртуализации (Vserver, OpenVZ) и контейнеризации через docker. Тоже не работает, они используют то же самое ядро что и хост-система, а значит используют те же значения системного таймера. Снова отпадает.

Да, ну? У вас ниже в статье по сути идёт подгрузка faketime, а ядро общее. Так что это в каком-то смысле противоречие. Ну, и раз докер работает через cgroups/namespaces, то прямолинейным выглядит путь как по ссылке https://lwn.net/Articles/766089/

kish4ever May 27 2020 at 07:25

И тут тоже спасибо за подсказку. Этого никто в нашей команде не находил во время отбора гипотез. Но оно будет работать только если экземпляры базы данных разные и запущены как разные контейнеры, а для cdb/pdb опять бы пришлось все равно делать что-то свое.

idubonos May 27 2020 at 07:16

Добрый день!
На уровне экземпляра (не знаю, как работает в PDB, думаю, затронет только конкретный контейнер) можно еще использовать:
alter system set fixed_date = '2017-04-01 12:34:56';
и затем после тестов
alter system set fixed_date = 'NONE';

Show the best of all time