Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Sean Chittenden writes:
>> Howdy.  Quick chump patch: if libpq finds a ~/.pgpass but can't stat
>> it, print something to stderr letting the user know.  If someone went
>> out of their way to put a .pgpass file in place, if they can't read
>> it, it seems worth while to alert them to the fact that it's not being
>> used (ex: root creates a .pgpass file but forgets to chown it).

> You cannot assume that stderr is meaningful in all applications using
> libpq.  (Consider PHP.)  I think you need to report this using the normal
> error reporting mechanism.

But it's not an error; we must not fail the connection attempt just
because of this.

I'd suggest using the NOTICE mechanism, except that during connection
setup the client app has not yet had a chance to set a notice processor,
so Peter's objection still holds.

On the whole, I'm not sure we have a problem we need to fix there.  If
.pgpass isn't readable, it's not going to take that long for the user to
figure it out.

OTOH --- there already is a print-to-stderr in the code for the case
where .pgpass exists and has insecure permissions.  Taking Peter's
complaint into account, I wonder whether we shouldn't make that case a
hard error (connect failure) to ensure that the user notices the problem
and does something about it promptly.  IIRC, the postmaster refuses to
start if $PGDATA has insecure permissions, so there's precedent.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to