Re: pg_hba_lookup function to get all matching pg_hba.conf entries

From: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Date: 2015-12-28 10:09:56
Message-ID: CACACo5TauS=0jKfnbmD-95C1Am8ntaYNLPzxh-fJWbZwM=bPig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

> On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> >> 1. Have you considered re-loading the HBA file upon call to this
> function
> >> in a local context instead of keeping it in the backends memory?
> >
> > Aside from the security questions, please consider that this feature
> should
> > work similarly to the current implementation of the pg_file_settings
> view,
> > namely it tells you about what is *currently* in the on-disk files, not
> > necessarily what is the active setting in the postmaster's memory.
> > A backend could not be entirely sure about the postmaster's state anyway;
> > and even if it could be, one of the major applications for features like
> > this is testing manual changes to the files before you SIGHUP the
> > postmaster. So re-reading the files on each usage is a Good Thing, IMO,
> > even if it sounds inefficient.
> >
> >> 2. I also wonder why JSONB arrays for database/user instead of TEXT[]?
> >
> > Yes, that seems rather random to me too.
>
> Here I attached updated patch with the following changes,
> - Local loading of HBA file to show the authentication data
> - Changed database and user types are text[]
>

Still this requires a revert of the memory context handling commit for
load_hba() and load_ident(). I think you can get around the problem by
changing these functions to work with CurrentMemoryContext and set it
explicitly to the newly allocated PostmasterContext in
PerformAuthentication(). In your function you could then create a
temporary context to be discarded before leaving the function.

I still think you should not try to re-implement check_hba(), but extend
this function with means to report line skip reasons as per your
requirements. Having an optional callback function might be a good fit (a
possible use case is logging the reasons line by line).

Thank you.
--
Alex

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-12-28 10:23:08 Re: WIP: bloom filter in Hash Joins with batches
Previous Message Masahiko Sawada 2015-12-28 09:38:59 Re: Freeze avoidance of very large table.