> > 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.
>
> If you are inside a GUI application, it's entirely likely that
> stderr is hooked up to /dev/null. I think Peter's complaint has
> great force --- libpq has no business assuming it's okay to write on
> stderr. The entire reason we provided a notice-processor hook is to
> get away from that assumption.
Do you mean setting something in conn->errorMessage.data, use
defaultNoticeProcessor(), or fprintf(conn->Pfdebug....) ?? If the 1st
or 3rd, conn isn't setup, is it? In the 2nd, it's just an
fprintf(stderr...) call with no way of overriding the output stream.
Would you like me to add an interface that'd allow stderr to be
redirected in the case of defaultNoticeProcessor()? Problem is this
interface wouldn't be thread safe then. I'd think it'd be nice to
have something that'd take variable length arguments for error
reporting too.
> >> 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.
>
> Yeah, in fact I've been reconsidering that. If we fail to stat the
> file, we should just return quietly; but if we can stat it but not
> open it, it's reasonable to assume there's something wrong that
> ought to be fixed. It's difficult to say that this shouldn't be a
> hard error if you accept my suggestion that world readability should
> be an error.
>
> If we do take that viewpoint then the problem goes away, since we
> can just report all the reportable conditions as connection-failure
> messages.
We can stat a file that is owned by root and not readable to the user.
In such a case, because the user isn't able to read the file, all
libpq applications will fail making it effectively possible for the
system admin to shut off all applications that use libpq. In the
other case of the permissions being unsafe, however, the user should
have the ability to chmod the file. I actually think libpq _should_
chmod(2) the file for the user, issue a warning if it succeeds stating
that it chmod(2)'ed the file, or if it fails, then it should abort the
connection process. Rationale being that if it exists, and the user
can't chmod it because they don't have access to it, then again,
you've DoS'ed the user trying to use an application that uses libpq.
If the ~/.pgpass file has inappropriate permissions and isn't owned by
the user, then libpq should not use the .pgpass file, continue on its
merry way, issue a warning, but not abort the connection process.
Hrm, this is almost turning into a mother knows best kind of scenario
where libpq is trying to out think the DBA.... is there a flag/env
var that can be set so that libpq drops its I know better than you
attitude in the event of a complex setup? A real world example from
an Oracle shop I used to work at: ~/.pgpass is owned by the user,
group owned by the dba group, and password rotation is managed by the
dba group.
-sc
--
Sean Chittenden
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
