On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr
<oleksandr.shulgin@zalando.de> wrote:
> On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi <kommi.haribabu@gmail.com>
> wrote:
>>
>> On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.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
