Re: Patch to be verbose about being unable to read ~/.pgpasss... - Mailing list pgsql-patches

> > 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.

stderr is hooked up to the error logs under Apache, which is the
normal error reporting mechanism.  I thought about adding a test to
see if stderr is writable, but given that better than 99% of the time
it will be, I didn't see the point, esp since the above case regarding
the permissions, doesn't.

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

Agreed, though one train of thought is that if someone did put a
.pgpass file in place that isn't readable, it should be known that
their efforts are being wasted in vein.  In the case of an unreadable
.pgpass, I'd like to know about it even if its stale that way I can
remove it or make it usable.  Having any kind of password hanging
around on the file system isn't a good policy and only invites trouble
in the event of a breach.

> 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.

I agree it's not a huge problem, but if there's one in place for a
given user and it's not usable or is being improperly used, then the
library _should_ point it out in some fashion.  Since the user has the
ability to chmod the file, it seems prudent to point this out (even
possibly chmod(2) the file for them given we're already know what the
result is going to be).  If root chown'ed the .pgpass file, however,
it _doesn't_ make sense to continue in the connection process in the
event that a user is no longer given access to the DB, but it also
makes sense to point out to the user that the reason they're being
asked for their password is because their .pgpass file is unreadable.
It would have saved me a few minutes instead of double checking that I
had the file format setup correctly.  Soooo, I figured I'd correct
this to prevent future bits of time from being wasted hunting down
brain dead mistakes: very likely there are huge numbers of admins that
are less competent, skilled, or familiar with libpq than I or those
reviewing the patch so it may take others much more time to diagnose
the problem.  It's little niceties like this that make using a library
pleasant to use, IMHO.

> 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.

This wouldn't be a bad idea, though frustrating for those that are
caught off guard by it... worth a mention in the release notes for
sure and can likely only be done at a major release point (7.4).

-sc

--
Sean Chittenden