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