Re: [PATCH] New predefined role pg_manage_extensions - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: [PATCH] New predefined role pg_manage_extensions
Date
Msg-id CAOzEurSGnvW3TyyHqBgS_cPr+SGc_DHa3B5_cfSJ66VzsOoEnw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] New predefined role pg_manage_extensions  (Michael Banck <mbanck@gmx.net>)
Responses Re: [PATCH] New predefined role pg_manage_extensions
List pgsql-hackers
On Thu, Jan 16, 2025 at 3:31 PM Michael Banck <mbanck@gmx.net> wrote:

I agree with this idea.
I think it is natural to delegate a part of superuser privileges to
another role because superuser privilege is too strong.

> > In general, this concept is rather dubious. Why should we have such a
> > dangerous pre-defined role?
>
> Well, I would say pg_execute_server_program could be regarded as a
> precedent.

Exactly. pg_execute_server_program can escalate to superuser
privileges, so pg_manage_extensions is not the only dangerous
pre-defined role.

> I do think having a whitelist of allowed-to-be-installed extensions
> (similar/like https://github.com/dimitri/pgextwlist) makes sense
> additionally in today's container/cloud word where the local Postgres
> admin might not have control over which packages get installed but wants
> to have control over which extension the application admins (or whoever)
> may create, but that is another topic I think.

To use a certain extension, you may need to install the
postgresql-contrib package. In that case, is there a way to restrict
extensions other than the required one? Or is it unnecessary to impose
such restrictions?

Regards,
Shinya Kato



pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: Bertrand Drouvot
Date:
Subject: Re: Make pg_stat_io view count IOs as bytes instead of blocks