Re: [patch] fix dblink security hole

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] fix dblink security hole
Date: 2008-09-21 20:24:16
Message-ID: 9377.1222028656@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
> If we push the responsibility back to dblink, we might as well export
> conninfo_parse() or some wrapper thereof and let dblink simply check for
> a non-null password from the very beginning.

That's not totally unreasonable, since we already export the
PQconninfoOption struct ...

> Or perhaps we should modify conninfo_parse() to throw an error if it
> sees the same option more than once. Then dblink could prepend
> pgpassfile (or ignore_pgpass) to the beginning of the connstr and not
> have to worry about being overridden. Not sure if the backward
> compatibility hit is worth it though.

... but I think I like the second one better; multiple specifications of
an option seem like probably a programming error anyway. It's a close
call though. Exporting the parse code might enable other uses besides
this one.

In either case we'd still need a check after connection to verify that
the password actually got *used*, so I guess that
PQconnectionUsedPassword isn't dead, just incomplete.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2008-09-21 20:39:09 Re: Proposal: move column defaults into pg_attribute along with attacl
Previous Message Dmitry Koterov 2008-09-21 20:20:37 Re: Foreign key constraint for array-field?