On Sun, Apr 21, 2024 at 11:20 AM yudhi s <learnerdatabase99@xxxxxxxxx> wrote:
On Sun, Apr 21, 2024 at 8:13 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> On Sunday, April 21, 2024, yudhi s <learnerdatabase99@xxxxxxxxx> wrote:
>> Are you saying something like below, in which we first create the
>> function from super user and then execute the grant? But doesn't that mean,
>> each time we want to create a new event trigger we have to be again
>> dependent on the "super user" to modify the security definer function?
> Dynamic SQL. See “execute” in plpgsql.
You might as well just give that user superuser and be done with it.
It's foolish to imagine that you have any shred of security left
if you're letting a user that's not 100.00% trusted write event
triggers. (Much less execute any SQL command whatsoever, which
is what it sounds like David is suggesting you create a function
to do.)So do you mean , we should not create the event trigger using the "security definer" , rather have the super user do this each time we have to create the event trigger?
I suggest you share a script that demonstrates exactly what you are trying to accomplish. Which event triggers you need to create from the application and what the functions those triggers call do.
Actually , I am not very much aware about the security part, but is it fine to give the super user privilege to the application user(say app_user) from which normally scripts/procedures get executed by the application, but nobody(individual person) can login using that user.
app_user should not be superuser nor own objects in the database. The role that performs schema migrations for the database should be able to become superuser via set role so when doing migrations if there is a need to do something as superuser it is possible but explicit.
It is during schema migrations that event triggers are expected to be installed, not in response to some user hitting your website and having your middleware execute some SQL while connected as the app_user role.
David J.
