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

From Pavel Stehule
Subject Re: Restricting Direct Access to a C Function in PostgreSQL
Date
Msg-id CAFj8pRC_hwQAgaDrzVARC7EY+QRC=6jD7OKXt-p8W7Qu==Wtiw@mail.gmail.com
Whole thread Raw
In response to Re: Restricting Direct Access to a C Function in PostgreSQL  (Ayush Vatsa <ayushvatsa1810@gmail.com>)
Responses Re: Restricting Direct Access to a C Function in PostgreSQL
List 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 by date:

Previous
From: Ayush Vatsa
Date:
Subject: Re: Restricting Direct Access to a C Function in PostgreSQL
Next
From: Ayush Vatsa
Date:
Subject: Re: Restricting Direct Access to a C Function in PostgreSQL