|
|
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Привет сообществу Postgres. Необходимо использовать xpath_table в своей хранимке объявленной как security definer. Но xpath_table "не видит" созданную в моей хранимке времянку. При том, что напрямую курсор из времянки данные возвращает. День секаса привел к мысли, что проблема в том, что встроенные функции (а может не все?) объявлены как SECURITY INVOKER. Выхода вижу два: - либо дать права на времянку исполняющему пользователю Код: plsql 1. - либо сделать xpath_table security definer Код: plsql 1. Как поступить правильнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 11:41 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
RUS 21, можно сделать свою обертку к функции и объявить ее security definer. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 12:03 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Не понял. По сути моя написанная функция уже и есть обертка и она уже security definer: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Вот в таком виде запуск из под непривилегированного пользователя дает permission denied for relation tmp_xml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 12:12 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
RUS 21, какая у вас версия сервера? Покажите select version(); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 14:17 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Последнего недавно качал. Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 14:23 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
RUS 21 Код: sql 1. 2. 3. 4. 5. 6. Вот в таком виде запуск из под непривилегированного пользователя дает permission denied for relation tmp_xml Ошибку даёт не запуск самой хранимки, а чтение из второго курсора. Вы создали таблицу и курсор под пользователем user1, а читать из таблицы и курсора пытаетесь под пользователем user2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 14:43 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
ЁшОшибку даёт не запуск самой хранимки, а чтение из второго курсора. Вы создали таблицу и курсор под пользователем user1, а читать из таблицы и курсора пытаетесь под пользователем user2. Согласен. Ошибка вылетатет во время fetch. И что вы посоветуете в таком случае? Задача - организовать работу с БД максимально урезанных в правах пользователей посредством хранимок владельца основной схемы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 15:17 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Вообще интересное конечно поведение Код: 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. первая строчка курсора выполняется под user1, а вторая, под user2 :-) PS: по поводу вопроса — не знаю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 15:41 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
В Oracle создаешь хранимку как definer (по-умолчанию), открываешь курсор и не паришься о правах конкретного пользователя на таблицы, используемые в этой хранимке. Лишь бы дать эти права владельцу хранимок и дать права пльзователям на запуск этих хранимок. А тут получается, если в хранимке создаются объекты (времянки) и выплевываемый курсор использует их, то в момент фетча у меня не хватит прав.. В общем, я склоняюсь к мысли раздавать права на времянки (первый вариант). Только вопрос: как отработает создание временной таблицы и раздача прав на неё current_user при одновременном запуске такой хранимки двумя пользователями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 17:16 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
RUS 21В Oracle создаешь хранимку как definer (по-умолчанию), открываешь курсор и не паришься о правах конкретного пользователя на таблицы, используемые в этой хранимке. Лишь бы дать эти права владельцу хранимок и дать права пльзователям на запуск этих хранимок. А тут получается, если в хранимке создаются объекты (времянки) и выплевываемый курсор использует их, то в момент фетча у меня не хватит прав.. В общем, я склоняюсь к мысли раздавать права на времянки (первый вариант). Только вопрос: как отработает создание временной таблицы и раздача прав на неё current_user при одновременном запуске такой хранимки двумя пользователями? 1)Временные таблицы - они локальны для backend так что можно хоть 200 одинаковых временных таблиц сделать в 200 коннектах (и у каждого backend она своя будет со своей структурой и правами). 2)Временные таблицы в PostgreSQL очень дорогое решение, я бы посоветовал стараться без них делать а через return query возвращать весь ответ из хранимки, и если уж надо потом по кускам вычитывать - открывать курсор снаружи функии. Или вам 2+ разных result set хочется из функции вернуть? Но это всеравно можно без временных таблиц сделать. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 17:28 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Как вариант - создать нормальную nologging таблицу, дать на нее права всем, иметь в ней колонку PID или другой идентификатор сессии. Так в принципе можно разделять данные между сессиями. Ну и обдумать уборку мусора из этой таблицы. Но если размеры разделяемых между сессиями данных позволяют, то лучше избежать временных таблиц вообще, как Максим советует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 18:34 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, да, чаще всего курсоров несколько и даже если один, то для клиента-приложения удобнее оперировать refcusor-ами. Спасибо за информацию. Временные таблицы будут использоваться только если есть сложная обработка/подготовка данных. В Oracle в выручали коллекции, ну и те же времянки (которые создаются заранее, а не по ходу действия в исполняемой хранимке). Sergei.Agalakov, спасибо. Идея понятна, но, думаю, это будет слишком.Оставим как запасной вариант, если создание времянок будет заметно тормозить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 08:26 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk2)Временные таблицы в PostgreSQL очень дорогое решение Максим, а что в них дорогого? Если то, что они пушут в WAL, то их можно же UNLOGGED сделать. Или есть ещё какие-то тормоза? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2014, 04:54 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
UKYMaxim Boguk2)Временные таблицы в PostgreSQL очень дорогое решение Максим, а что в них дорогого? Если то, что они пушут в WAL, то их можно же UNLOGGED сделать. Или есть ещё какие-то тормоза? В wal они конечно не идут... но вот создание временной таблицы это DDL со всем его overhead немаленьким. Вот 3 примера на моей тестовой базе: меряется время 100.000 вызовов в формате begin; select test(); commit; (в 1 коннекте): select фукция минимальная: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 100.000 вызовов - 10секунд т.е. 0.1ms на вызов тоже самое + запись 1 строки в обычную таблицу Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 100.000 вызовов - теже 10 секунд А вот теперь интересное - добавляем создание временной таблицы Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 100.000 вызовов занимают теперь заняло 60 секунд... т.е. в 6 раз дольше... Временные таблицы сами по себе быстрые а вот их создание - не очень... правильный режим использования - надо заранее их создавать в коннекте с базой и дальше пользоваться не создавая заново каждый раз внутри хранимки... или использовать для тяжелых и сложных расчетов где overhead на создание таблицы будет незаметен (но в 99% случаем можно обойтись без них). --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2014, 12:46 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
ЁшВообще интересное конечно поведение С разницей в год наступаю на те же грабли)) 1) Если в последовательности вызываемых хранимок есть security invoker, то при fetch курсора execution context открываемых курсоров для security-invoker-хранимок "сваливается" с юзера-владельца security-definer-хранимки в контекст пользователя, запустившего самую "верхнюю" хранимку. Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 2)Но если нет работы с курсорами, то все происходит как и предполагается при работе с security-definer-хранимками. Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 3)Вдогонку. Если в первом случае fetch происходит уже под верхним(сессионным) пользователем и его контекст оказывается "главнее", то если в последовательности хранимок все они security definer, то "сваливания" контекста не происходит и security-definer-матрешка отрабатывает как и должна. Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. По мне, так либо всегда контекст владельца (что есть суть security definer), либо всегда контекст сессионного юзера (тогда нафиг пытались реализовать security definer). Ёш, Maxim Boguk, не тянет на bug? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2015, 18:14 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
RUS 21, Я погонял ваши варианты. В общем тут вот какое дело: конструкция Код: plaintext Реально запрос выполняется при ПЕРВОМ вызове FETCH на этом курсоре. Мне кажется что Bug report писать бессмысленно, скажут что фича. Workaround (костыль! костыль!) можно вот такой вот сделать (выполнить cursor запрос внутри SECURITY DEFINER хранимки перед тем как его отдавать): Код: plsql 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. Код: plaintext 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. Может у кого то идеи будут лучше как красивее заэнфорсить инициализацию запроса из курсора перед тем как его из хранимки отдавать. PS: мое личное мнение что это баг конечно. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2015, 15:56 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, спасибо за проявленный интерес к теме. Maxim BogukРеально запрос выполняется при ПЕРВОМ вызове FETCH на этом курсоре. Мне тоже кажется, что это баг в обработке/хранении execution context при наличии вложенности хранимых процедур. Потому как в одном случае контекст доходит до этапа fetch правильно, а в другом, вследствие некорректной обработки, "сбрасывается". Maxim Bogukкостыль! костыль! А какой на ваш взгляд у этого костыля overhead (особенно в случае тяжелых для выборки первой записи планов)? Наверное незначительный? Что мы в клиенте начнем фетчить курсор, что мы в хранимке дернем одну запись..Возможно для курсора типа scroll какие-то дополнительные структуры создаются.. PS: в своем случае пока изменил тип хранимок pgagent`а на security definer. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 09:42 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Maxim BogukRUS 21, Мне кажется что Bug report писать бессмысленно, скажут что фича. и будут правы. т.к. по выходу из security definer мы вернулись в контекст invoker, а в нем на выполнение запроса курсора нет прав. это, думается, простое и стройное поведение. если же костылем открыли -- то ещё в контексте definer -- права и были. опять простое и стройное поведение. -- немного добавил ясности которая и так была Код: 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. ------------------- иначе надо объявлять с каким-то [отсутствующем пока в синтаксе] модификатором (добавить SQL кляузу в ) [DECLARE|OPEN] .... WITH ROLE ... ; -- тогда тоже будет простое и стройное поведение -- в момент OPEN проверяются права в текущем контексте , в момент fetch -- не проверяется ничто, ибо проверка перенесена в OPEN; (а все ф-ии в курсоре, если есть, выполняются в контексте ROLE. в т.ч. и "current_user" ). или включать дурочку [идти в отказ] в момент уже [DECLARE|OPEN], всегда и везде. ну и заодно "with hold" хотелось бы для plpgsql-cursors. иногда, когда соединение за клиентом можно удержать без ненужного (и плохо контролируемого) висяка клиентской транзы. Или его таки можно через динамику из хранимки открыть как SQL-cursor? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:10 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
И снова security definer)) Задались вопросом почему plpgsql-функции работают быстрее, чем sql. Pavel Stehule говорит, что нормальная имутабл-функция должна встраиваться в запрос и только тогда можно получить(негарантированное) ускорение от более оптимального плана выполнения и может быть обогнать кэшированный план plpgsql-функции.. http://www.postgresql.org/message-id/CAFj8pRCTRo-Y3+M2uYGjt2d4J0=KhRfbqRpSA1=rxbBkYoy4MQ@mail.gmail.com]http://www.postgresql.org/message-id/CAFj8pRCTRo-Y3 M2uYGjt2d4J0=KhRfbqRpSA1=rxbBkYoy4MQ@mail.gmail.com И так вроде бы и получается. Видим в плане развернутую sql-функцию.. НО! Если функция security definer, то фигвам. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: sql 1. Код: plaintext 1. 2. Код: sql 1. Код: plaintext 1. 2. Код: sql 1. О чем говорят мужчины- Немцы, как жить дальше? - Как, как? Каком кверху! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2015, 11:28 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
RUS 21, И это вполне логично... нельзя встроить (Inline) подзапрос выполняемый от другого пользователя (а security definer именно это). Такое поведение вполне ожидаемо и предсказуемо. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2015, 11:32 |
|
||
|
security definer встроенных функций
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, соглашусь. И в исходниках нашли Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2015, 12:05 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=109&tid=1997928]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
16ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 352ms |

| 0 / 0 |
