[HACKERS] Parsing of pg_hba.conf and authentication inconsistencies

The way pg_hba.conf is set up to be loaded/parsed now, we have:

postmaster: open and tokenize file (load_hba(), tokenize_file()).
backend: parse lines (parse_hba) and check for matches
(check_hba/hba_getauthmethod)

This means that the code in the postmaster is very simple, and it's
shared with the caching of the role and ident files.

It also means that we don't catch any syntax errors in the hba file
until a client connects. For example, if I misspell "local" on the first
line of the file (or just leave a bogus character on a line by mistake),
no client will be able to connect. But I can still do a pg_ctl reload
loading the broken file into the backend, thus making it impossible for
anybody to connect to the database. (when there's a broken line, we
won't continue to look at further lines in the file, obviously)

Is there any actual gain by not doing the parsing in the postmaster,
other than the fact that it's slightly less shared code with the other
two files? If not, then I'd like to move that parsing there for above
reasons.

I've also noticed that authentication methods error out in different
ways when they are not supported. For example, if I try to use Kerberos
without having it compiled in, I get an error when a client tries to
connect (because we compile in stub functions for the authentication
that just throw an error). But if I use pam, I get an "missing or
erroneous pg_hba.conf file" error (because we #ifdef out the entire
option all over the place). I'd like to make these consistent - but
which one of them do people prefer?

//Magnus

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers