Re: [Extern] Re: postgres event trigger workaround

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Дмитрий Иванов <firstdismay(at)gmail(dot)com>
Cc: "Zwettler Markus (OIZ)" <Markus(dot)Zwettler(at)zuerich(dot)ch>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: [Extern] Re: postgres event trigger workaround
Date: 2022-01-15 05:01:18
Message-ID: 20220115050118.prd2kkky3ezhaozn@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

On Sat, Jan 15, 2022 at 08:36:21AM +0500, Дмитрий Иванов wrote:
> In my solution, all users don't need direct access to the schema because
> you have to use the functional API to access it. If you can manage users
> with functions, you can close the schema in the same way.
> Usually the function is executed with the permissions of the calling user,
> which requires permissions for all affected entities. However, if you
> specify the "SECURITY DEFINER" parameter at creation, the function will be
> executed with the owner's permissions. The owner of the function has no
> login permissions but has permissions on the affected entities. In this way
> you will close the schema from the roles that have rights to the role
> management functions.

Sure you can solve most problems with that. But you can't create a database
(or a tablespace) from a function so this approach wouldn't cover all of OP's
needs, as different approach would be needed for role and db creation.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mladen Gogala 2022-01-15 05:19:11 Re: List all tables from a specific database
Previous Message Дмитрий Иванов 2022-01-15 03:36:21 Re: [Extern] Re: postgres event trigger workaround