Parsing of pg_hba.conf and authentication inconsistencies
От | Magnus Hagander |
---|---|
Тема | Parsing of pg_hba.conf and authentication inconsistencies |
Дата | |
Msg-id | 48943DD2.7000902@hagander.net обсуждение исходный текст |
Ответы |
Re: Parsing of pg_hba.conf and authentication inconsistencies
Re: Parsing of pg_hba.conf and authentication inconsistencies |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: