From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: dblink connection security |
Date: | 2007-07-01 20:29:26 |
Message-ID: | 16716.1183321766@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> bool PQconnectionUsedPassword(const PGconn *conn);
> Maybe PQconnectionUsedAuthToken() to mean "data supplied by the client",
> including other potential future mechanisms?
Well, that'd not solve the pre-existing problem of how to tell whether
to request a password. If we had a fairly clear idea of what other
sorts of auth tokens might be involved, I'd be willing to go that way,
but I distrust our ability to design it today.
>> This idea isn't usable as a back-patch, however, because adding
>> functions to existing libpq versions is too chancy. What we could
>> possibly do in back versions is, if dblink_connect is called by a
>> non-superuser, first issue the connection attempt without any password
>> and reject if that doesn't fail.
> Why not just require the connect string to contain a password for
> non-superusers?
Doesn't fix the problem, because you don't know whether libpq actually
used the password or not.
> I won't have time to work on this until the end of the coming week --
No hurry, I don't think there are any short-term plans for a release.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-01 20:32:28 | Re: dblink connection security |
Previous Message | Magnus Hagander | 2007-07-01 20:20:07 | Re: dblink connection security |