[Dbconfig-common-devel] Re: postgresql server and .pgpass

[sean finney]

hi martin,

(putting dbconfig-common-devel back into the cc for posterity, hope you
don't mind)

On Fri, May 12, 2006 at 08:17:44AM +0200, Martin Pitt wrote:
> > this is a problem in the automagic dbconfig-common system, because
> > we need to use .pgpass to avoid passing sensitive data on the cmdline.
> > since it would be a BAD THING to go overwriting /root/.pgpass, i
> > accomplish this by creating a temp directory and temporarily setting
> > HOME to this directory, and placing a .pgpass file in there.  now
> > in 8.x this trick fails.
> 
> That's the part I don't understand so far: why would you create a new
> db user with a password and then store that password unencrypted on
> the hard disk in a .pgpass file? If you do want to authenticate users
> with a password, they should enter it themselves. If they are supposed
> to connect without a password, then please use ident authentication.

this method is only used during the setup/upgrade/purge phases, and
the file is only stored on the system in a temporary directory long
enough to execute the command.  i believe this is the safest way
to provide the authentication information because any other method
would involve using cmdline flags or enviornment variables that others
could see.

basically, after prompting the local admin for all relevant info
(username, host, auth via password/ident, etc), we create the database
as the dbadmin user, and then bootstrap it using the normal dbuser.

to avoid halting the install process with needless password prompts
(after all, we did just prompt the admin for these password), all of
the "run sql command" functions do something like this:

if authmethod = password
	tmphome = mktemp -d
	print_credentials > tmphome/.pgpass
	env HOME=tmphome run_sql_command
	rm -rf tmphome

this this is somewhat simplified, but illustrates how it works in a
nutshell.

> I'm not sure whether this was done deliberately. I. e.
> getpwent(geteuid()) is much more reliable than $HOME. E. g. $HOME is
> not correct when using sudo. If upstream is fine with patching this
> back, I'd be happy to do it, but I would prefer to hear their opinion
> first. (They were not happy with me doing unapproved patches in the
> past; I'm not particularly worried about this, but I still appreciate
> their opinion).

okay.  i don't really so much care *how* it's done, but i need some
way of specifying an alternate .pgpass, or some other way of supplying
the credentials automatically.  maybe there's already another way to do
this that i don't know.  furthermore, it would be nice if this method
were backwards compatible (i.e. something ignored by the previous
version if i did both at the same time), but i'm willing to put some
version checks in place if it's necessary.

if they'd rather not let $HOME mess with the getpwent functions that's
fine, but it would be nice if they could provide another way (cmdline
option, differently named environment variable) to override it.

> > - can you suggest another way of providing this information?
> 
> Once I understand what exactly you want to achieve, I'll do my best.

does that help?  if so i'd appreciate if you could forward this along.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20060512/927f7b20/attachment.pgp