On Wed, Jun 8, 2022 at 2:51 PM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > At Wed, 08 Jun 2022 07:05:09 +0200, Laurenz Albe <laurenz.a...@cybertec.at> > wrote in > > 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> > > Looks fine. I'd like to add something like "If needed, depriving > unprivileged users of relevant user mappings will prevent such remote > executions that happen at planning-time."
I agree on that point; if the EXPLAIN done on the remote side is really a problem, I think the user should revoke privileges from the remote user specified in the user mapping, to prevent it. I’d rather recommend granting to the remote user privileges consistent with those granted to the local user. Best regards, Etsuro Fujita
