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-22 01:15:34 |
Message-ID: | 19554.1222046134@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:
> Tom Lane wrote:
>> So that seems to tilt the decision towards exposing the conninfo_parse
>> function. Joe, do you want to have a go at it, or shall I?
> Here's a first shot.
Hmm ... one problem with this is that the caller can't tell
failure-because-out-of-memory from failure-because-string-is-bogus.
That doesn't matter for your proposed dblink patch, but I had been
thinking of documenting that if someone wanted to get an error message
explaining just what was wrong with the conninfo string, they could
try to open a connection with it and use the resulting failure message.
But it's just barely conceivable that the PQconnect call *wouldn't* fail
because out-of-memory. (Not very likely in a sequential application,
but definitely seems possible in a multithreaded app --- some other
thread could release memory meanwhile.) Is it worth having the
PQconninfoParse function pass back the error message to avoid this
corner case? The API would be a lot more ugly, perhaps
int PQconninfoParse(const char *connstr,
PQconninfoOption **options,
char **errmsg)
okay: *options is set, *errmsg is NULL, return true
bogus string: *options is NULL, *errmsg is set, return false
out of memory: both outputs NULL, return false
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2008-09-22 01:43:02 | Re: [patch] fix dblink security hole |
Previous Message | Joe Conway | 2008-09-22 00:44:58 | Re: [patch] fix dblink security hole |