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?
Not sure. That would break any attempts of implementing delegation in
Kerberos for dblink, but I don't know if we're interested in doing that
anyway.
BTW, what I wrote about delegation before is wrong, of course. If
delegation worked, in that pg requested a delegation enabled ticket and
exported it through the dblink connection, it would authenticate as the
user that authenticated to the original database, not as the superuser
or anything like that. So delegation would actually be perfectly secure.
If implemented properly of course.
//Magnus