Re: On login trigger: take three

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Greg Nancarrow <gregn4422(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On login trigger: take three
Date: 2020-12-11 16:05:26
Message-ID: 656537e8-9409-a7d6-1790-3423a8f7be9b@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.12.2020 18:40, Pavel Stehule wrote:
>
> is not correct. It makes it not possible to superuser to disable
> triggers for all users.
>
>
> pg_database_ownercheck returns true for superuser always.

Sorry, but I consider different case: when normal user is connected to
the database.
In this case pg_database_ownercheck returns false and trigger is not
disabled, isn't it?

>
> Also GUCs are not associated with any database. So I do not
> understand why  this check of database ownership is relevant at all?
>
> What kind of protection violation we want to prevent?
>
> It seems to be obvious that normal user should not be able to
> prevent trigger execution because this triggers may be used to
> enforce some security policies.
> If trigger was created by user itself, then it can drop or disable
> it using ALTER statement. GUC is not needed for it.
>
>
> when you cannot connect to the database, then you cannot do ALTER. In
> DBaaS environments lot of users has not superuser rights.

But only superusers can set login triggers, right?
So only superuser can make a mistake in this trigger. But he have enough
rights to recover this error. Normal users are not able to define on
connection triggers and
should not have rights to disable them.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-12-11 16:27:27 Re: On login trigger: take three
Previous Message Heikki Linnakangas 2020-12-11 15:44:29 Re: Feature Proposal: Add ssltermination parameter for SNI-based LoadBalancing