Re: Custom oauth validator options - Mailing list pgsql-hackers

From Zsolt Parragi
Subject Re: Custom oauth validator options
Date
Msg-id CAN4CZFNywvG59B+nBgD1_1fHE2uODBH3EcF_gwLmC7Y5U6Ru4Q@mail.gmail.com
Whole thread Raw
In response to Re: Custom oauth validator options  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
> I think I need to do more staring at the intersection of GUC
> registration and session_preload_libraries, because my memory of the
> order of operations was faulty. I won't be able to do that before the
> holidays, most likely.

Maybe I'm missing something, but why do we need
session_preload_libraries? oauth_validator_libraries is processed
earlier, it can already define sighup GUCs, it should also work with a
new level around that. I assume that if postgres gets another
authentication plugin point later, it will be executed around the same
place, during authentication, so that also shouldn't be an issue.

The question is if non-validator libraries should be able to define
PGC_HBA variables. If yes, then either

* we don't validate that all HBA variables are valid - if somebody
made a typo, we can't detect it
* we add a sighup guc with a manual whitelist
* require shared preload libraries or oauth_validator_libraries,
because those are loaded before or during authentication
* require session_preload_libraries. We proceed with authentication
even with unresolved HBA variables, but abort the connection if there
are still unknown parameters after loading session preload.



pgsql-hackers by date:

Previous
From: Daymel Bonne Solís
Date:
Subject: [PATCH] psql: Allow connection string parameters as positional arguments
Next
From: Kirill Reshke
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)