[Dbconfig-common-devel] Status of "editing pg_hba.conf"

[Karsten Hilbert]

On Thu, Jan 25, 2007 at 10:45:42AM +0100, sean finney wrote:

> *however*, i think at this point it's become more or less a moot issue,
> because (iirc) the default postgres configuration allows password-based
> authentication for connections on the loopback device, so applications
> requiring passwords should "just work" on the local host
Well, see, that may not be enough, I fear. The situation is
this:

- assuming a default PostgreSQL install

- user wants to install/upgrade GNUmed server package

- apt-get runs as root
	- GNUmed installer runs as root
	- installer can SU to postgres

- GNUmed installer connects postgres to template1
	- why: to create GNUmed database owner "gm-dbo" and
	       group roles inside PG
	- this can be done by su-ing to user postgres

- GNUmed creates PG user gm-dbo and group roles
	- no equivalent user exists at the OS level
	- should there for authentication ?

- GNUmed connects superuser to GNUmed template db
	- why: to verify template database hash
	- the template database can anything from
	  template1 to another (previous) GNUmed
	  database
	- this can be done by su-ing to user postgres

- GNUmed creates new GNUmed database
	- owned by PG user gm-dbo

- GNUmed connects superuser to new GNUmed database
	- why: to run postgres-only DDL
	- this sets up procedural languages and
	  SECURITY-DEFINER stored procs for adding
	  users to the database
	- this can be done by su-ing to user postgres

- GNUmed connects gm-dbo to new GNUmed database
	- why: to run the rest of the GNUmed DDL such
	       that everything is owned by gm-dbo
	- not every PG object can be given explicit
	  ownership yet (we still support PG 7.4)
	- this can be done by requiring md5 access
	  for gm-dbo even on UNIX domain sockets
!!!!!!!!!!!!
 	- for that, however, we need to edit pg_hba.conf
	- personally, I am fine with popping up an editor
	  with pg_hba.conf in it and showing instructions
	  on what to do
!!!!!!!!!!!!

Martin, are you listening on this list ?

>  and for remote password-connections,
> there's not much to be done there since it's beyond the scope of our
> abilities to edit files on the remote host.
No question about that.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346