From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Jerry Sievers <gsievers19(at)comcast(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HBA files w/include support? |
Date: | 2014-02-14 14:35:42 |
Message-ID: | CABUevEw3YEsYVBQJ6H9RA6aMq73seFUctGuV+T3o6g_QztLGXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 14, 2014 at 3:32 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Feb 13, 2014 at 11:28:45PM -0600, Jerry Sievers wrote:
> > > One issue with this is that pg_hba.conf is order sensitive, which could
> > > become a trap for the unwary if includes are used carelessly.
> >
> > Indeed.
> >
> > The other thing that comes to mind, is that as opposed to
> > postgresql.conf and the include scenario there... one can do show all or
> > query from pg_stat_activity just to see what setting they ended up
> > with.
> >
> > I'm not aware of any way to probe what hba rules are loaded at runtime
> > and thus, debugging hba config changes not really possible.
>
> In an ideal world we would have a tool where you could plug in a
> username, database, IP address, and test pg_hba.conf file and it would
> report what line is matched.
>
I almost wrote a function you could call to do that a while back. I never
finished it though :)
It's not all that hard to do, but requires some minor refactoring of how
the HBA code works.
What would also be useful would be to be able to use such a function/tool
against a different file than the current HBA one, to verify *before* you
reload...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-02-14 14:36:51 | Re: HBA files w/include support? |
Previous Message | Stephen Frost | 2014-02-14 14:34:59 | Re: HBA files w/include support? |