Re: Patch to be verbose about being unable to read ~/.pgpasss...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch to be verbose about being unable to read ~/.pgpasss...
Date: 2003-06-23 19:05:29
Message-ID: 11049.1056395129@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Sean Chittenden <sean(at)chittenden(dot)org> writes:
> I maintain that having a security concern in PasswordFromFile() cause
> the connection to abort as the default behavior is a bad idea.

That is a legitimate concern. Doesn't seem like we have any really
clean way to satisfy all the needs here.

One idea I was toying with was to have PasswordFromFile set a flag in
the PGconn struct indicating that .pgpass has permissions problems.
Then some later routine could check the flag and issue the notice if
needed, giving the app a chance to install its notice handler
beforehand. However, this begs the question of *which* later routine
should do this. PQexec would once have been the obvious choice, but
as of 7.4 it's quite possible that some apps would never use it.
And I don't want to sprinkle the issue through a bunch of different
routines. Maybe PQgetResult would be a safe bet that all apps would
go through (directly or indirectly). Comments?

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Greg Sabino Mullane 2003-06-23 20:48:41 Consistent timestamp input
Previous Message Sean Chittenden 2003-06-23 18:23:42 Re: Patch to be verbose about being unable to read ~/.pgpasss...