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() a
SECURITY DEFINER function, and revoke access to my_func_extended() for
all other roles.
This sounds reasonable, and can be one of the options.

> Dunno how
complicated the logic in my_func() is, if that makes sense.
Actually my_func_extended already exists hence I don't want 
to touch its C definition, nor wanted to duplicate the logic.

>The SPI API is not difficult, and this looks like best option
Sorry didn't understand this part, are you suggesting I can have called 
my_func_extended() through SPI inside my_func(), but didnt that also required 
my_func_extended() declaration present in SQL ? And If that is present then
anyone 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.

 

Regards
Ayush
AWS

В списке pgsql-hackers по дате отправления: