[HACKERS] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] About pg_hba.conf
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] About pg_hba.conf
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] About pg_hba.conf
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
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] About pg_hba.conf
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
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] About pg_hba.conf
[EMAIL PROTECTED] (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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
