Re: Restricting Direct Access to a C Function in PostgreSQL
| От | Ayush Vatsa |
|---|---|
| Тема | Re: Restricting Direct Access to a C Function in PostgreSQL |
| Дата | |
| Msg-id | CACX+KaPzN_q9uOjcr=JzYG6EWQ7JKwev2j+ozwUNn1Kx5LX4qA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Restricting Direct Access to a C Function in PostgreSQL (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: Restricting Direct Access to a C Function in PostgreSQL
|
| Список | pgsql-hackers |
Thanks for the responses.
all other roles.
> I would go with the GRANT approach. Make my_func() a
SECURITY DEFINER function, and revoke access to my_func_extended() forall 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.
Regards
Ayush
AWS
В списке pgsql-hackers по дате отправления: