[Dbconfig-common-devel] Why does dbconfig-common use a none exiting local user

Karsten Hilbert Karsten.Hilbert at gmx.net
Thu Jan 19 18:31:23 UTC 2006


On Thu, Jan 19, 2006 at 07:01:28AM -0500, sean finney wrote:

> i was referring to the default postgres configuration for debian
> systems, which i believe support local ident and local/remote
> password based authentication.
I think that's correct.

> but from a dbc perspective we're currently only concerned with :
> 
> - whether a password is required
I understand your motivations but the problem is that there
is no way of finding out short of re-implementing the pg_hba
handling code from PostgreSQL. One would have to properly
parse pg_hba, pg_ident and possibly arbitrary other ident
map files. The only other alternative is to ask the user -
and she can be buggy, too.

Hence dbc should *assume* that a password is needed and
supply it. If it ain't used - fine.

> - whether we need to run code as a specific local user
This may be necessary but is at the discretion of the
application using dbc. The package maintainer should know
and there should be a means to *tell* dbc what user to run
as.

> and the psql utility takes care of the rest.
It will, given the above.

> > To make a long story short: the dbc default should be to
> > supply a password and not worry about whether it is needed
> > or not. If it isn't needed it isn't used.
> 
> that's an interesting idea i hadn't considered.  it'd clean up the
> code a bit, anyway :)
Same approach we use in GNUmed. The logon dialog asks for a
password. If the user *knows* they don't need one they can
leave it blank or input anything they desire - it won't make
a difference as the PG server won't ask for it anyways.

> in any case, i'm thinking about changing the default pgsql behavior to
> use passwords instead of ident, as it's far more common for the former.
Sounds reasonable.

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



More information about the Dbconfig-common-devel mailing list