Обсуждение: About pg_hba.conf
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) Regards, Gevik
Gevik Babakhani wrote: > 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) > System recovery might also be a reason (if you for some reason make your data in DB unworkable). Svenne
Gevik Babakhani schrieb: > 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) No, you need the ability to override the settings with external options to get access to a misconfigured database. (Well of course you could run postgres in single user mode to get that too, but it would be a little inconvient...) Regards Tino
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 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)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
I agree. Security is a good reason to have the pg_bha.conf around. I guess
it would make the TODO item a bit harder to develop hence one has to read
and write the file to support the future SQL commands too. I also looked
at the code for a moment; perhaps using a yacc/lex mechanism would make
things easier to develop the TODO item. Like creating a simple parser for
the config file to be able to read and or update it.
Reagrds,
Gevik.
> 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 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)
>
> --
> Robert Treat
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>
>
gevik@xs4all.nl ("Gevik Babakhani") writes:
> 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)
It's a frequently asked question...
The trouble is, what if you accidentally lock all of the users out?
How do you fix that, if nobody can connect to submit SQL commands?
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/lsf.html
"Ahhh. A man with a sharp wit. Someone ought to take it away from him
before he cuts himself." -- Peter da Silva
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