Re: Error from the foreign RDBMS on a foreign table I have no privilege on - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Error from the foreign RDBMS on a foreign table I have no privilege on
Date
Msg-id 97a1892429bc3460dc4afb727c9be68a9ba20584.camel@cybertec.at
Whole thread Raw
In response to Re: Error from the foreign RDBMS on a foreign table I have no privilege on  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Wed, 2022-06-08 at 13:06 +0900, Kyotaro Horiguchi wrote:
> At Wed, 08 Jun 2022 12:09:27 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> > At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe <laurenz.albe@cybertec.at> wrote in 
> > > If anything, it should be done in the FDW, because it is only necessary if the
> > > FDW calls the remote site during planning.
> > > 
> > > The question is: is this a bug in postgres_fdw that should be fixed?
> > 
> > It's depends on what we think about allowing remote access trials
> > through unprivileged foreign table in any style.  It won't be a
> > problem if the system is configured appropriately but too-frequent
> > estimate accesses via unprivileged foreign tables might be regarded as
> > an attack attempt.
> 
> In other words, I don't think it's not a bug and no need to fix.  If
> one want to prevent such estimate accesses via unprivileged foreign
> tables, it is enough to prevent non-privileged users from having a
> user mapping.  This might be worth documenting?

I take Tom's comment above as saying that the current behavior is fine.
So yes, perhaps some documentation would be in order:

diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index b43d0aecba..b4b7e36d28 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -274,6 +274,14 @@ OPTIONS (ADD password_required 'false');
        but only for that table.
        The default is <literal>false</literal>.
       </para>
+
+      <para>
+       Note that <command>EXPLAIN</command> will be run on the remote server
+       at query planning time, <emphasis>before</emphasis> permissions on the
+       foreign table are checked.  This is not a security problem, since the
+       subsequent error from the permission check will prevent the user from
+       seeing any of the resulting data.
+      </para>
      </listitem>
     </varlistentry>

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: tablesync copy ignores publication actions
Next
From: Peter Smith
Date:
Subject: Re: bogus: logical replication rows/cols combinations