Re: Regrading TODO item alerting pg_hba.conf from SQL

On Sun, Apr 16, 2006 at 03:37:42PM +0200, Tino Wildenhain wrote:
> > Apart from the complaint that this makes no attempt to take care of the
> > fact that entires in pg_hba.conf are order sensetive. Where is that
> > found in this syntax? What about pg_ident.conf?
>
> there is actually no proof of the current order depency is really
> a good idea. Other access lists work without that constraint.

For something that may not be a good idea, it's awfully popular.
Firewall chains, tcpwrappers (hosts.allow), SSH config to name but a
few. I think you need to demonstrate that an order independant solution
is at least as flexble. Even network routing tables, being a common
case where order doesn't matter, get layered into tables with an order
to deal with complex routing setups.

I don't think you can get away from having an order because you have
several attributes all equally important (connection type
(local/remote), source (ip), ssl(yes/no), database name, user name).
How do you decide which to use if multiple match?

> > you layer your above grant syntax into those chains. This allow people
> > to switch between different auth methods quickly by switching files,
> > while allowing people who want to do everything in the database can do
> > so too.
>
> Even with in database rules only you can do the switches - you remove
> all entries, keeping your current connection and then bring them
> back when you are ready. Just a matter of some SQL commands in a script.

But I think you need to keep the concept of "commenting out". Disabling
a rule without removing it. And you havn't dealt with the central
administration aspect (farm out config files).

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.