Re: GRANT USAGE on FOREIGN SERVER exposes passwords

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Yetter <nyetter(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GRANT USAGE on FOREIGN SERVER exposes passwords
Date: 2015-02-05 15:13:51
Message-ID: 5885.1423149231@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> All that having been said, it wouldn't be crazy to try to invent a
> system to lock this down, but it *would* be complicated. An
> individual FDW can call its authentication-related options anything it
> likes; they do not need to be called 'password'. So we'd need a way
> to identify which options should be hidden from untrusted users, and
> then a bunch of mechanism to do that.

It's also debatable whether this wouldn't be a violation of the SQL
standard. I see nothing in the SQL-MED spec authorizing filtering
of the information_schema.user_mapping_options view.

We actually are doing some filtering of values in user_mapping_options,
but it's all-or-nothing so far as the options for any one mapping go.
That's still not exactly supportable per spec but it's probably less of a
violation than option-by-option filtering would be.

It also looks like that filtering differs in corner cases from what the
regular pg_user_mappings view does, which is kinda silly. In particular
I think we should try to get rid of the explicit provision for superuser
access.

I was hoping Peter would weigh in on what his design considerations
were for these views ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-02-05 15:28:55 Early Setup of instrumentation information in pg_stat_statements
Previous Message Robert Haas 2015-02-05 14:57:34 Re: GRANT USAGE on FOREIGN SERVER exposes passwords