Re: Regrading TODO item alerting pg_hba.conf from SQL - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Regrading TODO item alerting pg_hba.conf from SQL
Date
Msg-id 20060416130046.GA6591@svana.org
Whole thread Raw
In response to Regrading TODO item alerting pg_hba.conf from SQL  (Gevik Babakhani <pgdev@xs4all.nl>)
Responses Re: Regrading TODO item alerting pg_hba.conf from SQL  (Tino Wildenhain <tino@wildenhain.de>)
List pgsql-hackers
On Sun, Apr 16, 2006 at 01:08:36PM +0200, Gevik Babakhani wrote:
> Folks,
>
> I would like to start a discussion regarding the TODO item "%Allow
> pg_hba.conf settings to be controlled via SQL"

<snip>

> 1. What do we think about removing the pg_hba.conf functionality keeping
> the connection information in a table. This would mean no more
> pg_hba.conf and when something goes wrong with the table, pg has to be
> started in standalone mode to correct the errors.

Why does it have to be one or the other? While in-database is nice,
having it as a seperate file makes central administration easier
because you can just distribute files. You can also easily compare two
sites to see how the rules differ.

You also have to think about sites that perform maintainence. Currently
they just replace the file and SIGHUP. When the maintainence is
complete, put the file back and SIGHUP again. This is a feature hard to
replicate with in database stuff.

> 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?

> 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.

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
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.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.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.

pgsql-hackers by date:

Previous
From: "Marko Kreen"
Date:
Subject: Re: Is full_page_writes=off safe in conjunction with
Next
From: Tino Wildenhain
Date:
Subject: Re: Regrading TODO item alerting pg_hba.conf from SQL