Re: [HACKERS] postgres_fdw super user checks

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

In response to

Browse pgsql-hackers by date

  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