Robert Treat wrote:
On Thursday 06 April 2006 09:45, Gevik Babakhani wrote:
Hello Folks,
This may be a dumb question but please bear a moment with me.
About the TODO item “%Allow pg_hba.conf settings to be controlled via
SQL“: If in the future we could configure the settings by SQL commands,
assuming the settings are saved in an internal table, what would be the
need for a pg_hba.conf file anymore. (except for the backward
compatibility of cource)
I've generally been keeping the idea around as a foot-gun saver for when
people lock themselves out of the database via the sql commands; this could
give them a fall back mechanism to do authentication without something more
drastic.
I don't see this. You could connect using a standalone postgres to fix
things, or you could provide a switch or postgresql.conf setting to load
hba settings from a file rather than a table. There are many ways of
providing a mechanism to get around messed up configuration.
I think some people might also prefer the pg_hba.conf method as more secure,
since it requires local access to modify, making remote exploits a wee bit
harder (admin tools that provide this functionality not-withstanding)
This is the illusion of security. You don't need any admin tools to
overwrite the file remotely. COPY will do it quite happily. TIAS.
However, there has been disagreement is on what an alternative API might
look like. See very recent discussion on this point.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
