...
>> 2. What do we think about the SQL command to be. Would it be like the
>> following or another syntax.
>>
>> GRANT
>> CONNECTION [LOCAL | HOST | HOSTSSL | HOSTNOSSL ]
>> ON [ ALL | mydatabase1 ]
>> TO [ ALL | user1,user2,user3 ]
>> FROM 127.0.0.1/32
>> METHOD [ TRUST | REJECT | MD5 ...... ]
>
> 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.
>> 3. Could someone clarify the design decisions regarding pg_hba.conf
>> file? Why was it done the why it is today? (Tom? Bruce?)
>
> Not sure if there was a design. It was created at some point and
> evolved.
Maybe now we can do a real design? No need to continue on the wrong
path (if it is wrong).
> Now, to just suggest something I've been thinking of. Maybe a way of
> thinking about it is similar to firewall chains in linux. You keep
> pg_hba.conf but allow it to refer to a new auth type "chain blah". Then
not that "chains" are the only and the best solution to firewall rules
out there :-)
> 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.
Kind regards
Tino