Re: postgres_fdw super user checks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw super user checks
Date: 2017-09-14 20:08:08
Message-ID: CA+TgmoZjKYhTV+j9MC50tbwioxJnnNgS8x_H=FQ_UNuKJjxzTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> I think that foreign tables ought to behave as views do, where they run as
> the owner rather than the invoker. No one has talked me out of it, but no
> one has supported me on it either. But I think it is too late to change
> that now.

That's an interesting point. I think that you can imagine use cases
for either method. Obviously, if what you want to do is drill a hole
through the Internet to another server and then expose it to some of
your fellow users, having the FDW run with the owner's permissions
(and credentials) is exactly right. But there's another use case too,
which is where you have something that looks like a multi-user
sharding cluster. You want each person's own credentials to carry
over to everything they do remotely.

I feel like the USER MAPPING stuff is a pretty clunky and annoying way
of trying to make this work, no matter which of those use cases you
happen to have. But I'm not exactly sure what would be better,
either, and like you say, it's a bit late to be breaking compatibility
at this point.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-09-14 20:13:46 Re: Patches that don't apply or don't compile: 2017-09-12
Previous Message Tom Lane 2017-09-14 20:05:42 Pre-existing bug in trigger.c