Stephen Frost <sfr...@snowman.net> writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers