Re: On login trigger: take three
| От | Pavel Stehule |
|---|---|
| Тема | Re: On login trigger: take three |
| Дата | |
| Msg-id | CAFj8pRCxdQgHy8Mynk3hz6pFsqQ9BN6Vfgy0MJLtQBAUhWDf3w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: On login trigger: take three (Greg Nancarrow <gregn4422@gmail.com>) |
| Ответы |
Re: On login trigger: take three
|
| Список | pgsql-hackers |
út 8. 12. 2020 v 1:17 odesílatel Greg Nancarrow <gregn4422@gmail.com> napsal:
On Fri, Dec 4, 2020 at 9:05 PM Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
>
> As far as I understand Pavel concern was about the case when superuser
> defines wrong login trigger which prevents login to the system
> all user including himself. Right now solution of this problem is to
> include "options='-c disable_session_start_trigger=true'" in connection
> string.
> I do not know if it can be done with pgAdmin.
> >
As an event trigger is tied to a particular database, and a GUC is
global to the cluster, as long as there is one database in the cluster
for which an event trigger for the "client_connection" event is NOT
defined (say the default "postgres" maintenance database), then the
superuser can always connect to that database, issue "ALTER SYSTEM SET
disable_client_connection_trigger TO true" and reload the
configuration. I tested this with pgAdmin4 and it worked fine for me,
to allow login to a database for which login was previously prevented
due to a badly-defined logon trigger.
yes, it can work .. Maybe for this operation only database owner rights should be necessary. The super user is maybe too strong.
There are two maybe generic questions?
1. Maybe we can introduce more generic GUC for all event triggers like disable_event_triggers? This GUC can be checked only by the database owner or super user. It can be an alternative ALTER TABLE DISABLE TRIGGER ALL. It can be protection against necessity to restart to single mode to repair the event trigger. I think so more generic solution is better than special disable_client_connection_trigger GUC.
2. I have no objection against client_connection. It is probably better for the mentioned purpose - possibility to block connection to database. Can be interesting, and I am not sure how much work it is to introduce the second event - session_start. This event should be started after connecting - so the exception there doesn't block connect, and should be started also after the new statement "DISCARD SESSION", that will be started automatically after DISCARD ALL. This feature should not be implemented in first step, but it can be a plan for support pooled connections
Regards
Pavel
Pavel, is this an acceptable solution or do you still see problems
with this approach?
Regards,
Greg Nancarrow
Fujitsu Australia
В списке pgsql-hackers по дате отправления: