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

From Tom Lane
Subject Re: [patch] fix dblink security hole
Date
Msg-id 7104.1221962950@sss.pgh.pa.us
Whole thread Raw
In response to Re: [patch] fix dblink security hole  (Joe Conway <mail@joeconway.com>)
Responses Re: [patch] fix dblink security hole  ("Marko Kreen" <markokr@gmail.com>)
Re: [patch] fix dblink security hole  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> Good point -- I'll look into that and post something tomorrow. How does 
> "requirepassword" sound for the option? It is consistent with 
> "requiressl" but a bit long and hard to read. Maybe "require_password"?

Well, no, because it's not requiring a password.

Perhaps "ignore_pgpass"?
[ looks at code a moment... ]  Actually, there's another possibility.
I see that the code already allows the location of .pgpass to be
specified via the environment variable PGPASSFILE, but very
non-orthogonally fails to have an equivalent conninfo option.
So here's a more concrete proposal: fix it so that pgpassfile is
also a conninfo option, and allow "pgpassfile = none" to silently
suppress use of the pgpass file.  (You could almost get there today
with putenv("PGPASSFILE=/dev/null"), except that (a) it would generate
complaints in the postmaster log, and (b) we probably don't want dblink
messing up the backend environment settings for possible other uses
of libpq.)

BTW, a possible hole in this scheme would be if a user could supply a
conninfo string that was intentionally malformed in a way that would
cause a tacked-on pgpassfile option to be ignored by libpq.  We might
need to add some validity checks to dblink, or tighten libpq's own
checks.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Foreign key constraint for array-field?
Next
From: Tatsuo Ishii
Date:
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch