Thread: Should database = all in pg_hba.conf match a replication connection?
I spent a fair amount of time just now being confused about why
pg_hba.conf restrictions on replication connections didn't seem to be
getting enforced. After looking at the code, I realize that my entry
with database = "replication" was indeed getting rejected as not
matching, but then the hba code was falling through and matching an
entry with database = "all". This is not the behavior I expected after
looking at the docs; the docs seem to imply that SR connections must
match an explicit replication entry in pg_hba.conf in order to succeed.
Should we change this? It seems to me to be a good thing on security
grounds if replication connections can't be made through a generic
pg_hba entry. If we don't change it, the docs need some adjustment.
regards, tom lane
On Apr 20, 2010, at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I spent a fair amount of time just now being confused about why > pg_hba.conf restrictions on replication connections didn't seem to be > getting enforced. After looking at the code, I realize that my entry > with database = "replication" was indeed getting rejected as not > matching, but then the hba code was falling through and matching an > entry with database = "all". This is not the behavior I expected > after > looking at the docs; the docs seem to imply that SR connections must > match an explicit replication entry in pg_hba.conf in order to > succeed. > > Should we change this? It seems to me to be a good thing on security > grounds if replication connections can't be made through a generic > pg_hba entry. +1. ...Robert
On Wed, Apr 21, 2010 at 8:49 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Apr 20, 2010, at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I spent a fair amount of time just now being confused about why >> pg_hba.conf restrictions on replication connections didn't seem to be >> getting enforced. After looking at the code, I realize that my entry >> with database = "replication" was indeed getting rejected as not >> matching, but then the hba code was falling through and matching an >> entry with database = "all". This is not the behavior I expected >> after >> looking at the docs; the docs seem to imply that SR connections must >> match an explicit replication entry in pg_hba.conf in order to >> succeed. >> >> Should we change this? It seems to me to be a good thing on security >> grounds if replication connections can't be made through a generic >> pg_hba entry. > > +1. +1 too. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Fujii Masao <masao.fujii@gmail.com> writes:
> On Wed, Apr 21, 2010 at 8:49 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Apr 20, 2010, at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Should we change this? �It seems to me to be a good thing on security
>>> grounds if replication connections can't be made through a generic
>>> pg_hba entry.
>>
>> +1.
> +1 too.
Done.
regards, tom lane
On Apr 20, 2010, at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I spent a fair amount of time just now being confused about why > pg_hba.conf restrictions on replication connections didn't seem to be > getting enforced. After looking at the code, I realize that my entry > with database = "replication" was indeed getting rejected as not > matching, but then the hba code was falling through and matching an > entry with database = "all". This is not the behavior I expected > after > looking at the docs; the docs seem to imply that SR connections must > match an explicit replication entry in pg_hba.conf in order to > succeed. > > Should we change this? It seems to me to be a good thing on security > grounds if replication connections can't be made through a generic > pg_hba entry. +1. ...Robert
On Tue, 2010-04-20 at 19:06 -0400, Tom Lane wrote: > Should we change this? It seems to me to be a good thing on security > grounds if replication connections can't be made through a generic > pg_hba entry. That's a good change. -- Simon Riggs www.2ndQuadrant.com