From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HBA files w/include support? |
Date: | 2014-02-14 14:32:16 |
Message-ID: | 20140214143216.GA474@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 presume that a simple scenario involving just 1 level of includes not
> too difficult to grok but nested includes sure might be a foot gun
> unless there was a way to dump the resulting configs somehow.
>
> Thus pasting hba files together externally a more reliable approach.
You certainly would not have a visual idea of what line is matched
_first_. We have the same problem with postgresql.conf includes, though
the last match wins there --- not sure if that makes it any easier.
I think one concern is that pg_hba.conf is more security-oriented than
postgresql.conf.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-02-14 14:33:23 | Re: HBA files w/include support? |
Previous Message | David Beck | 2014-02-14 14:28:57 | Re: New hook after raw parsing, before analyze |