Re: [patch] fix dblink security hole

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [patch] fix dblink security hole
Дата
Msg-id 7104.1221962950@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [patch] fix dblink security hole  (Joe Conway <mail@joeconway.com>)
Ответы Re: [patch] fix dblink security hole
Re: [patch] fix dblink security hole
Список 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 по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: Foreign key constraint for array-field?
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Common Table Expressions (WITH RECURSIVE) patch