Re: Restricting Direct Access to a C Function in PostgreSQL
От | Pavel Stehule |
---|---|
Тема | Re: Restricting Direct Access to a C Function in PostgreSQL |
Дата | |
Msg-id | CAFj8pRC_hwQAgaDrzVARC7EY+QRC=6jD7OKXt-p8W7Qu==Wtiw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Restricting Direct Access to a C Function in PostgreSQL (Ayush Vatsa <ayushvatsa1810@gmail.com>) |
Ответы |
Re: Restricting Direct Access to a C Function in PostgreSQL
|
Список | pgsql-hackers |
ne 11. 8. 2024 v 15:34 odesílatel Ayush Vatsa <ayushvatsa1810@gmail.com> napsal:
Thanks for the responses.> I would go with the GRANT approach. Make my_func() aSECURITY DEFINER function, and revoke access to my_func_extended() for
all other roles.This sounds reasonable, and can be one of the options.> Dunno howcomplicated the logic in my_func() is, if that makes sense.Actually my_func_extended already exists hence I don't wantto touch its C definition, nor wanted to duplicate the logic.>The SPI API is not difficult, and this looks like best optionSorry didn't understand this part, are you suggesting I can have calledmy_func_extended() through SPI inside my_func(), but didnt that also requiredmy_func_extended() declaration present in SQL ? And If that is present thenanyone can call my_func_extended() directly.
no, my proposal is write your my_func in C - like Heikki proposes, then my_func_extended should not be visible from SQL, and then you don't need to solve this issue.
RegardsAyushAWS
В списке pgsql-hackers по дате отправления: