Re: Allow file inclusion in pg_hba and pg_ident files
От | Julien Rouhaud |
---|---|
Тема | Re: Allow file inclusion in pg_hba and pg_ident files |
Дата | |
Msg-id | 20220327095222.zacjwdgeagbczqe6@jrouhaud обсуждение исходный текст |
Ответ на | Re: Allow file inclusion in pg_hba and pg_ident files (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Allow file inclusion in pg_hba and pg_ident files
|
Список | pgsql-hackers |
Hi, On Fri, Mar 25, 2022 at 08:18:31PM +0900, Michael Paquier wrote: > > Now looking at 0002. The changes in hba.c are straight-forward, > that's a nice read. Thanks! > if (!field) { \ > - ereport(LOG, \ > + ereport(elevel, \ > (errcode(ERRCODE_CONFIG_FILE_ERROR), \ > errmsg("missing entry in file \"%s\" at end of line %d", \ > IdentFileName, line_num))); \ > + *err_msg = psprintf("missing entry at end of line"); \ > return NULL; \ > } \ > I think that we'd better add to err_msg the line number and the file > name. This would become particularly important once the facility to > include files gets added. We won't use IdentFileName for this > purpose, but at least we would know which areas to change. Also, even > if the the view proposes line_number, there is an argument in favor of > consistency here. I don't really like it. The file inclusion patch adds a file_name column in both views so that you have a direct access to the information, whether the line is in error or not. Having the file name and line number in error message doesn't add any value as it would be redundant, and just make the view output bigger (on top of making testing more difficult). I kept the err_msg as-is (and fixed the ereport filename in the file inclusion patch that I indeed missed). > > +select count(*) >= 0 as ok from pg_ident_file_mappings; > > I'd really like to see more tests for this stuff I didn't like the various suggestions, as it would mean to scatter the tests all over the place. The whole point of those views is indeed to check the current content of a file without applying the configuration change (not on Windows or EXEC_BACKEND, but there's nothing we can do there), so let's use this way. I added a naive src/test/authentication/003_hba_ident_views.pl test that validates that specific new valid and invalid lines in both files are correctly reported. Note that I didn't update those tests for the file inclusion. Note that those tests fail on Windows (and I'm assuming on EXEC_BACKEND builds), as they're testing invalid files which by definition prevent any further connection attempt. I'm not sure what would be best to do here, apart from bypassing the invalid config tests on such platforms. I don't think that validating that trying to connect on such platforms when an invalid pg_hba/pg_ident file brings anything. > + a.pg_usernamee, > [...] > + <entry role="catalog_table_entry"><para role="column_definition"> > + <structfield>pg_username</structfield> <type>text</type> > > Perhaps that's just a typo in the function output and you > intended to use pg_username? Yes that was a typo :) It's correctly documented in catalogs.sgml, so I just fixed pg_proc.dat and rules.out. > + /* Free parse_hba_line memory */ > + MemoryContextSwitchTo(oldcxt); > + MemoryContextDelete(identcxt); > Incorrect comment, this should be parse_ident_line. Indeed. I actually fixed it before but lost the change when rebasing after the 2nd hbafuncs.c refactoring. I also fixed an incorrect comment about pg_hba_file_mappings.
Вложения
В списке pgsql-hackers по дате отправления: