Re: SQL/MED compatible connection manager

From: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED compatible connection manager
Date: 2009-03-05 08:59:38
Message-ID: 49AF947A.3030809@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-03-05 09:28:21 Re: SIGHUP during recovery
Previous Message KaiGai Kohei 2009-03-05 08:38:00 Re: Updates of SE-PostgreSQL 8.4devel patches (r1668)