* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Having @include and directory.d-style capabilities for pg_hba.conf *and*
> > pg_ident.conf would make managing larger environments much better.
>
> I'm a little suspicious of this, mainly because pg_hba searching is
> necessarily linear (and none too cheap per-entry). I think anyone
> who tries to use a set of entries large enough to really need multiple
> files is going to have pain.
It would depend on the connection rate- some of these environments have
low connection rate but quite a few users (eg: corporate database
server). As expressed up-thread, and in my own experience, people are
already doing this by building up the files themselves, so I don't agree
that performance would be so bad that this isn't worth it. Not everyone
is using PG to back their website. Improving performance would always
be good too, or perhaps providing another mechanism which performs
better when there are more entries.
> We already have various methods for making one pg_hba entry do the
> work of many; for instance, IP-subnet entries, wildcards, and role
> references. And you can use database CONNECT privilege grants as
> another substitute for fine-grained pg_hba entries.
Yes, but those entries all have to agree on the exact authentication
method, including any mappings or other options which are passed through
pg_hba.conf. Also, CONNECT is only true/false, it doesn't have any
ability to consider source-IP, SSL, etc.
> I'd be interested to see a real use-case where those things aren't
> an adequate substitute for a pg_hba rule set that's too large to
> fit conveniently in one file. Maybe we could identify another
> pg_hba abstraction technique we need to support.
Being able to 'fit' inside of one file is wholly in the eye of the
beholder and isn't terribly relevant either. Larger installations will
be using puppet, chef, or one of the other configuration management
systems and will want to use even small/independent files rather than
having to write code which fools around with the one file approach. The
files I have in /etc/cron.d/ aren't particularly large, but it's really
nice to be able to independently manage and deploy them without
templating them.
Also, all of the above ignores the pg_ident side of the house, which is
even worse as you need an entry for every user, period, if you're using
client-side SSL certificates or Kerberos/GSSAPI-based authentication
with full princ names.
> In short: I suspect this approach may be fixing the wrong thing.
I'm curious what you're thinking would be the right thing to fix here?
Thanks,
Stephen
