Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to