* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Whether this is a realistic expectation given the wording of the SQL-MED
> standard is unclear.
I've only got a draft as of 2011-12 handy, but I'm not seeing anything
in the standard that cares one bit about the value of the options
specified for the FDW. All that's said is "Both the option name and the
permissible ranges of option values of a generic option are defined by
the foreign-data wrappers."
In my view, that means that if we give FDWs the ability to control
what's displayed for their options, we're well within the requirements
of the spec.
> 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.
I agree that we don't want to go there but I don't see this as leading
us in that direction.
> 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.
I don't agree with this, however. Being able to execute arbitrary SQL
on the remote side through a specific interface does not equate to
having the password and direct access to the remote server. Even if it
did, there are good reasons to not expose passwords, even to the user
whose password it is. We take steps to avoid exposing user's passwords
and password hashes in core and I do not see this case as any different.
Thanks,
Stephen