Stephen Frost <sfrost@snowman.net> writes:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost <sfrost@snowman.net> wrote:
>>> And I thought this was about FDW options and not about dblink, really..
>> The OP is pretty clearly asking about dblink.
> I was just pointing out that it was an issue that all FDWs suffer from,
> since we don't have any way for an FDW to say "don't show this option",
> as discussed.
The dblink example is entirely uncompelling, given that as you said
somebody with access to a dblink connection could execute ALTER USER on
the far end. It's much more credible to imagine that someone might be
given a mapping for a postgres_fdw, oracle_fdw, etc foreign server with
just a few foreign tables, with the expectation that that couldn't be
parlayed into unfettered access to the remote server.
Whether this is a realistic expectation given the wording of the SQL-MED
standard is unclear.
I'm also concerned that if we take this on board as being a security
concern, it will mean that any time we make an effort to push some
construct we didn't before over to the remote end, we have to worry about
whether it would be a security breach to allow the local user to cause
that code to execute on the remote end. It's tough enough worrying about
semantic-equivalence issues without mixing hostile-user scenarios in.
So I would rather say that the baseline security expectation is that
granting a user mapping should be presumed to be tantamount to granting
direct access to the remote server with that login info. In that context,
being able to see the password should not be considered to be any big deal.
regards, tom lane
