On Wed, Jun 8, 2022 at 2:51 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> At Wed, 08 Jun 2022 07:05:09 +0200, Laurenz Albe <laurenz.albe@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
