Re: Allow file inclusion in pg_hba and pg_ident files

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Subject: Re: Allow file inclusion in pg_hba and pg_ident files
Date: 2022-03-25 11:18:31
Message-ID: Yj2lB7Dd2QimwWx6@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 24, 2022 at 04:08:38PM +0800, Julien Rouhaud wrote:
> On Thu, Mar 24, 2022 at 04:50:31PM +0900, Michael Paquier wrote:
>> And so, this first part has been applied as of d4781d8. I'll try to
>> look at 0002 shortly.
>
> Thanks!

Now looking at 0002. The changes in hba.c are straight-forward,
that's a nice read.

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.

+select count(*) >= 0 as ok from pg_ident_file_mappings;

I'd really like to see more tests for this stuff (pg_hba_file_rules is
not a great example in this area), where we could rely on something
for *nix platforms. Windows would provide some valid coverage as we
enable it by default for SSPI in pg_regress but that's not great for
the average Joe. One thing I thought about first is that
src/test/authentication/ does not test peer authentication at all,
which would map nicely with pg_ident.conf and some user mappings. So
we could have a new test there, that depends on how the backend reacts
when calling getpeereid(), making the results conditional. This would
be nice in the long-term.

As of a set of tests, I think that for now I would add two things, for
a total of four tests:
- Stick some queries on pg_ident_file_mappings only for Windows in
some of the tests of src/test/authentication/, say 001_password.pl.
One test should test for some valid fields. Another idea I have here
is to add some junk to pg_ident.conf, reload and check that an error
is generated (the missing field case on a given line).
- Do the same for src/test/kerberos/, with one positive and one
negative test with some junk in the ident conf file.

A last idea is to abuse of the fact that pg_ident is loaded even if we
don't use it: aka we could add some right and junky contents in
pg_ident.conf, then check its validity. Using one of the existing
tests may not be right, particularly if we finish by extending it, so
I would move that to a new fresh test script.

+ a.pg_usernamee,
[...]
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>pg_username</structfield> <type>text</type>

pg_usernamee sounds a bit weird as attribute name for the view. We
could stick to a simple postgres_user_name, or postgres_name, for
example. Perhaps that's just a typo in the function output and you
intended to use pg_username?

+ /* Free parse_hba_line memory */
+ MemoryContextSwitchTo(oldcxt);
+ MemoryContextDelete(identcxt);
Incorrect comment, this should be parse_ident_line.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-03-25 11:21:12 Re: logical decoding and replication of sequences
Previous Message Japin Li 2022-03-25 11:18:14 Re: turn fastgetattr and heap_getattr to inline functions