From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Nico Williams <nico(at)cryptonector(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, 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: [HACKERS] postgres_fdw super user checks |
Date: | 2017-11-28 20:54:11 |
Message-ID: | CA+Tgmoa5oVQ+DQi2LCvYaOoTP8KW8BtHvYNak4fL187PD4-JOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 5, 2017 at 1:16 PM, Nico Williams <nico(at)cryptonector(dot)com> wrote:
>> 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.
>
> Hmmm, I don't think that's really right.
>
> What I'd like instead is for the FDW client to tell the FDW server the
> session_user/current_user on behalf of which it's acting, and let the
> FDW server decide how to proceed. This could be done by doing a SET
> SESSION fdw.client.session_user... and so on.
Isn't that the same thing as the second use case I mentioned?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-11-28 21:06:21 | Re: [HACKERS] postgres_fdw super user checks |
Previous Message | Robert Haas | 2017-11-28 20:50:13 | Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump |