Robert Haas <robertmh...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
