Re: Questions and experiences writing a Foreign Data Wrapper

Robert Haas wrote:
>On Fri, Jul 22, 2011 at 12:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Well, if you read it that way, then CREATE USER MAPPING with an empty
>>>> option set is a no-op: the behavior of the FDW would be the same whether
>>>> you'd executed it or not.  Which doesn't seem to me to satisfy the
>>>> principle of least surprise, nor the letter of the spec.

>>> I think what they're saying is that they expect the credentials to be
>>> stored in the user mapping.  But that seems like a fairly silly
>>> requirement, since it's not difficult to imagine wanting all of your
>>> local users to connect to the remote side with the same set of
>>> credentials ...

>> But if you want that, you'd do CREATE USER MAPPING FOR PUBLIC.  What
>> disturbs me about this approach is that it'd have the effect of a public
>> mapping with no options existing by default, and being in fact
>> impossible to remove.  Now, depending on what the FDW chooses to require
>> in the way of options, that might not be insecure; but it sure seems
>> like a foot-gun waiting to fire on somebody.

> Maybe. On the other hand, I think there's a pretty strong usability
> argument against the way it works right now.

There is no specific way it works right now; in effect it's up to
the implementor of the foreign data wrapper to give these constructs
any possible meaning.
What could and should be done is document how we *intend* these things
to get used so that implementors can adhere to that.

I don't like to think of a user mapping as a means to restrict access
to the foreign data source, because in effect that is the same as
restricting access to the foreign table, which is the ACL's job.
Moreover, that would contradict the way file_fdw is currently
implemented.

After reading the standard, I'm inclined to think that lack of
user mapping is the same as having no foreign credentials. This might
be appropriate in some cases, e.g. where you give the PostgreSQL
OS user permission to connect without credentials (think "trust").
That might be desirable if you want to avoid storing passwords in
system catalogs. So I think that there should be no error
"user mapping not found", but instead you should get "could not
authenticate" from the remote.

CREATE USER MAPPING FOR PUBLIC would be a no-op in this case.

Yours,
Laurenz Albe