Re: [patch] fix dblink security hole - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [patch] fix dblink security hole
Date
Msg-id 9377.1222028656@sss.pgh.pa.us
Whole thread Raw
In response to Re: [patch] fix dblink security hole  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Foreign key constraint for array-field?
Next
From: Tom Lane
Date:
Subject: Re: Toasted table not deleted when no out of line columns left