Re: Restricting Direct Access to a C Function in PostgreSQL - Mailing list pgsql-hackers

From Ayush Vatsa
Subject Re: Restricting Direct Access to a C Function in PostgreSQL
Date
Msg-id CACX+KaPzN_q9uOjcr=JzYG6EWQ7JKwev2j+ozwUNn1Kx5LX4qA@mail.gmail.com
Whole thread Raw
In response to Re: Restricting Direct Access to a C Function in PostgreSQL  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Restricting Direct Access to a C Function in PostgreSQL
List pgsql-hackers
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.

Regards
Ayush
AWS

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: PG_TEST_EXTRA and meson
Next
From: Pavel Stehule
Date:
Subject: Re: Restricting Direct Access to a C Function in PostgreSQL