Re: Error from the foreign RDBMS on a foreign table I have no privilege on

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: euler(at)eulerto(dot)com, philflorent(at)hotmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Error from the foreign RDBMS on a foreign table I have no privilege on
Date: 2022-06-08 05:05:09
Message-ID: 97a1892429bc3460dc4afb727c9be68a9ba20584.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)ntt(at)gmail(dot)com> wrote in
> > At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2022-06-08 05:35:05 Re: bogus: logical replication rows/cols combinations
Previous Message Amit Kapila 2022-06-08 04:10:22 Re: tablesync copy ignores publication actions