Re: Parsing of pg_hba.conf and authentication inconsistencies

Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> To address Magnus' specific question, right now we store the pg_hba.conf
>>> tokens as strings in the postmaster. I am fine with storing them in a
>>> more native format and throwing errors for values that don't convert.
>>> What would concern me is calling lots of 3rd party libraries from the
>>> postmaster to validate items.
>> If I was unclear about that, that part was never part of what I
>> proposed. I'm only talking aobut parsing the syntax. The only external
>> calls in the code there now is the getaddrinfo calls to convert the IPs,
>> IIRC.
>
> That seems safe to me. The use of strings for the pg_hba.conf content
> was only for convenience; I can see the advantage of using a more
> natural format.

Attached is the patch I have so far. The only "extra" it adds over today
is that it allows the use of "ident" authentication without explicitly
specifying "sameuser" when you want that.

Other than that, it moves code around to do the parsing in the
postmaster and the maching in the backend. This means that now if there
is a syntax error in the file on a reload, we just keep the old file
around still letting people log into the database. If there is a syntax
error on server startup, it's FATAL of course, since we can't run
without any kind of pg_hba.

It also changes a couple of error cases to explicitly state that support
for a certain auth method isn't compiled in, rather than just call it a
syntax error.

Comments?

//Magnus