|
Странное поведение SECURITY DEFINER
|
|||
---|---|---|---|
#18+
Здравствуйте! Есть web-приложение, разработанное на версии 9.3. Все пользователи ходят в базу под одним аккаунтом (stapp), у которого минимум прав - usage основных схем и выполнение в них хранимых процедур. Необходимые процедуры сгенерированы пользователем postgres и имеют параметр SECURITY DEFINER. И все это благополучно работало, и я был уверен, что раз SECURITY DEFINER - значит внутри процедуры у меня права все есть. Но тут пришла пора перейти на версию 10. (Сейчас установлен 10.11 64 bit). И начались странности. В некоторых процедурах стали вылетать ошибки "Нет доступа к схеме pg_catalog". Вот пример такой процедуры: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50.
Здесь ошибка происходит во втором Select (Select Sum(os.amount) into v_ord...) А также во всех последующих. Поверхностный анализ показал, что не нравится серверу запрос, в котором вычисляется Sum(...) из нескольких таблиц, причем результат складывается в переменную. Для сравнения - часть другой процедуры, которая нормально работает: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
Подзапросы здесь практически те же, что в первой процедуре, но результат - таблица. И работает. Понятно, что можно дать stapp права usage pg_catalog. (Хотя и не хотелось бы.) Другой вариант - переписать все процедуры, выкидывающие ошибки, заменив присваивание "Into" на весьма кудрявый подзапрос. С процедурой sp_ware_view это получилось. Но во-первых, их всего около сотни, во-вторых, запросы получатся плохо читаемые. Есть ли другие варианты? А главное - что ему понадобилось в pg_catalog и почему он туда пошел не как postgres, а как stapp ? SECURITY DEFINER работает не совсем так, как я предполагал? Или можно что-нибудь настроить в сервере? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2021, 23:14 |
|
Странное поведение SECURITY DEFINER
|
|||
---|---|---|---|
#18+
Андрей Р., Возможность работы хоть чего то в принципе хоть как то не имея доступа на usage в pg_catalog никогда не постулировалась и не обещалась. Вот в 10той версии что то еще по этому поводу ломается. То что оно вообще раньше хоть как то работало в таком режиме - это скорее ошибка была (не должно было с моей т.з.). Так что правильный совет - никогда ни у кого не отбирать usage на pg_catalog (там много чудес может быть) и вернуть usage на pg_catalog для public. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2021, 23:52 |
|
Странное поведение SECURITY DEFINER
|
|||
---|---|---|---|
#18+
А где в документации написано, что все пользователи должны обязательно иметь доступ на usage в pg_catalog ? Я такого не нашел, может быть, упустил? И главный вопрос - почему SECURITY DEFINER не обеспечивает прав postgres (DEFINER) при работе процедуры? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2021, 19:39 |
|
Странное поведение SECURITY DEFINER
|
|||
---|---|---|---|
#18+
Андрей Р. А где в документации написано, что все пользователи должны обязательно иметь доступ на usage в pg_catalog ? Я такого не нашел, может быть, упустил? И главный вопрос - почему SECURITY DEFINER не обеспечивает прав postgres (DEFINER) при работе процедуры? pg_catalog - системная схема...и то что вообще позволяют на нее права менять - так у superuser 1000 методов себе в ногу выстрелить (вот вы нашли 1001й метод). права на pg_* не меняются и грязными руками никакие изменения в pg_* включая права не делаются. Никто не будет перечислять вещи которые НЕЛЬЗЯ делать с pg_* их там куда больше чем тех которые можно/безопасно делать... По умолчанию в pg_catalog все имеют доступ - вы это изменили (под вашу же ответственность )) вот вам и прилетело. Ну в общем случае например я бы сказал что для того чтобы начать запускать процедуру - ее сначала надо считать ее код и найти ее... а она в pg_catalog в таблице лежит куда доступа нет (вы же сами забрали)... и оно должно было вообще сразу говорить что не могу найти такую процедуру (по хорошему если бы все было сделано). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2021, 20:06 |
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1994091]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 160ms |
0 / 0 |