Re: GRANT USAGE on FOREIGN SERVER exposes passwords
От | Tom Lane |
---|---|
Тема | Re: GRANT USAGE on FOREIGN SERVER exposes passwords |
Дата | |
Msg-id | 5885.1423149231@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GRANT USAGE on FOREIGN SERVER exposes passwords (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: GRANT USAGE on FOREIGN SERVER exposes passwords
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: