Re: Keywords in pg_hba.conf should be field-specific

On 13 October 2010 00:28, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, Oct 9, 2010 at 11:13 AM, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
>> I understand that 'replication' is a keyword as far as the database
>> name is concerned, but I was surprised to find that it was treated as
>> a keyword in the username field also.  I had a look in
>> src/backend/libpq/hba.c, and next_token() appears to be completely
>> naive about this.  'replication' (along with 'all', 'sameuser',
>> 'samegroup' and 'samerole')  is treated as a keyword wherever it
>> appears, not just in the field where it is relevant.  next_token()
>> appends a newline to the end of the 'replication' username token, and
>> that's why the entry doesn't match my connection attempt.
>>
>> I suspect this is going to trip a lot of people up.  We could just
>> document it and tell people that if they want to use 'replication' as
>> a username, they'd better quote it in pg_hba.conf.  But I'd prefer to
>> actually solve the problem.
>
> Agreed. We should address that.
>

Hi folks,

Per the above discussion, I've prepared a patch to make keywords in
pg_hba.conf field-specific.

This patch takes a least-resistance approach to solving the problem.
next_token() continues to blithely append a newline character to any
token which *might* be a keyword, but the patch teaches
hba_parse_line() to be a bit more savvy about whether to take
next_token's word for it.

In the Database field, hba_parse_line() acknowledges 'all',
'sameuser', 'samegroup', 'samerole' and 'replication' as legitimate
keywords. Anything else is considered not a keyword, and if there is
a trailing newline it is stripped from the token (by just reassigning
it to NUL).

Likewise, in the Role field, only 'all' is considered legitimate.

In the Host field, we allow 'samehost' and 'samenet'.

The bottom line is that this makes 'replication' safe to use as a
username, no quoting required.

It seemed a little bit inelegant to allow next_token() to mark up a
keyword, only to ignore that marking later on, but as the number of
fields in each line is not decided until we parse it, there was no
sensible way to teach next_token() which field it was evaluating.

Added to the November CF.

Cheers,
BJ