Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Magnus Hagander (magnus@hagander.net) wrote:
>>> Kerberos is not affected either, because the server does not get a copy
>>> of the ticket. In theory it could be affected if the server requested a
>>> delegation enabled ticket, and exported it so it could be used, but none
>>> of these are done.
>
>> That's quite a stretch even there, imv anyway... It'd have to be put
>> somewhere a backend connecting would think to look for it, given that
>> the user can't change the environment variables and whatnot (I don't
>> think) of the backend process...
>
> Hmm. I think what you are both saying is that if the remote end wants
> Kerberos auth then you would expect a dblink connection to always fail.
> If so, then we still seem to be down to the conclusion that there
> are only three kinds of dblink connection:
> * those that require a password;
> * those that don't work;
> * those that are insecure.
>
> 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?
Joe
