Re: control pg_hba.conf via SQL

Tino Wildenhain wrote:
> Andrew Dunstan wrote:
>   
>> ISTM that the first requirement is for a sane API that will handle the
>> fact that HBA lines are ordered. Persistence in itself shouldn't be a
>> big problem - we already do that with some shared tables, iirc.
>>
>> so we might have some functions like:
>>
>>  insert_hba_rule(at_position int, connection_type text, username text,
>> dbname text, cidr_host text, method text)
>>  move_hba_rule(from_position int, to_position int)
>>  delete_hba_rule(at_position int)
>>
>> Inventing new SQL syntax might make things a bit tougher.
>>
>>     
>
> I dont think it has to be ordered preliminary. Since we are
> dealing with subnets and stuff - the ordering already lays
> in the data - just like routing tables work: most specific
> matches first.
>
> I could think of a solution where pg_hba.conf just
> overrides the database table (so you have a starting
> point with empty table and/or reentry in case of a
> mistake)
>
>
>   

We don't have the luxury of being able just to throw out old stuff 
because we think it might be neater to do it another way.  The current 
rules for HBA are order dependent. The issue raised as I understood it 
was not to invent a new scheme but to be able to manage it from inside a 
postgres session.

Of course, if we go for a new scheme that is not order dependent, then 
inventing a reasonable SQL syntax to support it becomes a heck of a lot 
easier. Something along the lines of GRANT/REVOKE CONNECT ... should do 
the trick.

Maybe we could do something like this: if there is a pg_hba.conf file 
present, then use it as now and ignore the access rights table - if 
someone does GRANT/REVOKE CONNECT while under pg_hba.conf then process 
it but issue a warning. Maybe there could also be an initdb switch that 
gave users a choice.

cheers

andrew