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
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 |