Peter Eisentraut wrote:
> I have been thinking about this for a great while now. I am not yet
> comfortable with how we manage the access rights here. We have
> restricted access to the user mappings catalog to hide passwords, but it
> is not entirely clear why a password must be stored in a user mapping.
> It could also be stored with a server, if we only want to use one global
> connection for everybody.
>
Hmm, in this case one would probably create a PUBLIC user mapping and
store the password there. But indeed, there could be other aspects
of the server that need to be kept secret.
> I think the proper way to handle it might be to introduce a new
> privilege type -- call it SELECT if you like -- that determines
> specifically whether you can *see* the options of a foreign-data
> wrapper, foreign server, or user mapping, respectively.
How about providing an optional masking function for the foreign data
wrapper. The function would accept the generic options array and remove/mask
any undesired options. Ordinary users would access the catalogs by views, and
only see the filtered or masked options. The owner and superuser would
still have to get the full options though.
Just an idea.
regards,
Martin
