Re: postgres_fdw super user checks

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw super user checks
Date: 2016-10-17 07:50:06
Message-ID: CAFjFpRdcfeGSTdi8HU+WaLU5wCQ2D31ZgbW-u-3d=NjkoSd+Bg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 17, 2016 at 11:48 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Mon, Oct 17, 2016 at 3:33 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> postgres_fdw has some checks to enforce that non-superusers must connect to
>> the foreign server with a password-based method. The reason for this is to
>> prevent the authentication to the foreign server from happening on the basis
>> of the OS user who is running the non-foreign server.
>>
>> But I think these super user checks should be run against the userid of the
>> USER MAPPING being used for the connection, not the userid of currently
>> logged on user.
>
> So, if the user mapping user is a superuser locally, this would allow
> any lambda user of the local server to attempt a connection to the
> remote server. It looks dangerous rather dangerous to me to authorize
> that, even if the current behavior is a bit inconsistent I agree.

A lambda user can use a user mapping same as a superuser if a. that
user mapping is public and/or b. it uses a view owned by super user
(RangeTblEntry::checkuser). When a is true but not b, the the user in
UserMapping is set to lambda and not superuser, so this patch is
correct here. If b is true, and lambda is able to access the view, the
superuser has granted it permissions to do so and thus intends to let
lambda use a super user user mapping. Since we trust super users to do
the right thing, I don't see why it's unsafe. Any other objects
accesses by lambda, will use a different user mapping based on the
object being accessed.

Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2016-10-17 08:53:47 pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Previous Message Masahiko Sawada 2016-10-17 07:39:51 Re: Optimization for lazy_scan_heap