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

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>
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-29 03:15:19
Message-ID: CAJrrPGc9vVLaVNe5ci9Eb2Z_u9N0ztSP6rHCDp6CXF6bJRmVmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr
<oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
> 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.

Thanks for the review. I didn't understand your point clearly.

In the attached patch, load_hba uses PostmasterContext if it is present,
otherwise CurretMemoryContext. PostmasterContext is present only
in the backend start phase.

> 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).

check_hba function is enhanced to fill the hba line details with
reason for mismatch.
In check_hba function whenever a mismatch is found, the fill_hbaline function is
called to frame the tuple and inserted into tuple store.

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
pg_hba_lookup_poc_v9.patch application/octet-stream 24.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-12-29 04:31:10 Re: Testing Postgresql 9.5 RC1 with Alfresco 5.0.d
Previous Message David Fetter 2015-12-28 23:57:37 Re: pam auth - add rhost item