On 13 October 2010 00:28, Fujii Masao <masao.fu...@gmail.com> wrote: > On Sat, Oct 9, 2010 at 11:13 AM, Brendan Jurd <dire...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
