Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> Tom Lane wrote:
>>> Would it be sensible to change dblink so that unless invoked by a
>>> superuser, it fails any connection attempt in which no password is
>>> demanded? I am not sure that this is possible without changes to libpq;
>>> but ignoring implementation difficulties, is this a sane idea from
>>> the standpoint of security and usability?
>
>> Possibly so. Remember that dblink is simply a libpq client. Doesn't that
>> mean that similar (although likely less severe) issues affect other
>> libpq clients executing locally, such as php or perl-dbi clients?
>
> Yeah, in principle this issue applies to any process performing a
> Postgres connection on behalf of someone else. (Whether there are any
> programs doing that, other than dblink, is debatable; but someday there
> may be.)
>
> The point about Kerberos delegation is interesting, but given that it
> doesn't work anyway, I'm not sure we need a solution for it right now.
Agreed.
> Here's a straw-man proposal that we could perhaps do for 8.3:
>
> 1. Invent a libpq connection-status function
>
> bool PQconnectionUsedPassword(const PGconn *conn);
>
> This returns true if the server had demanded a password during the
> authentication phase. Aside from solving the immediate problem, this
> can be useful for regular clients such as psql: it could be applied to a
> failed connection object to decide whether to prompt for a password
> (replacing the current egregious hack of strcmp'ing the error message).
Hmm. It would be better if it never actually completed an authentication
in the first place, but I don't see how we can do that given how the
protocol works.
We could add a connection string parameter that disables it, but that
doesn't really help since the backend moves into authenticated mode
before you can abort anyway.
And it's probably not a big issue anyway.
//Magnus
