On Thu, Oct 12, 2017 at 9:21 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Yes, that means that sometimes when superusers run things they get
> permission denied errors. That's always been the case, and is correct.
OK, let me try to summarize where we are with this.
Currently, postgres_fdw requires a password unless you are logged in
as a superuser. Jeff proposes to change that so that it requires a
password if you are EITHER logged in as a superuser OR using a
superuser's credentials - e.g. by selecting from a view created by a
superuser. Stephen and I propose that it should be one thing or the
other, and therefore that we should CHANGE the behavior to depend on
whose credentials you are using, not make it an either-or thing. So
when selecting from a view, whether or not you need a password would
depend entirely on who owns the view, not who you are. So that gives
us three options all of which are easy to implement: (1) leave it
alone [favored by nobody], (2) allow based on view owner OR current
user [favored by Jeff], (3) allowed based on view owner only [favored
by Stephen and me].
Taken in complete isolation, this would, maybe, constitute a marginal
consensus for option (2). However, Simon weighed in proposing a much
broader rethink in how foreign tables work -- letting them run with
either the owner's privileges or the accessor's privileges, rather
than always using the accessor's privileges as they do today. Nico
Williams, along with Jeff and I and others, had a lengthy discussion
of the desirability of some kind of authentication-forwarding
mechanisms. I view all of these questions as somewhat irrelevant to
the immediate decision insofar as we could do that stuff later, or
not, but they matter to the extent that they constitute tacit votes on
what to do about the patch on hand. Unless we can get a clearer
consensus here, I think we should just mark this patch as Rejected. I
hate to do nothing here, but neither doing something with which I
disagree nor trying to unilaterally impose my own opinion seem better.
Last call for other votes (or changes of opinion).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
