Joe Conway wrote:
I don't see anything documented under GRANT which controls privileges on
a mapping, and the USAGE on a server only controls what a user can see
by query. I assume that if the superuser creates a mapping from user foo
to server bar, foo can still use bar via the mapping, even i
Martin Pihlak wrote:
Usually it would have been the server owner who created those user
mappings in the first place -- so the passwords are already known
to him/her. Of course it is possible to create the mappings first
and later change the ownership of the server, thus exposing the
passwords to
Martin Pihlak writes:
> Usually it would have been the server owner who created those user
> mappings in the first place -- so the passwords are already known
> to him/her. Of course it is possible to create the mappings first
> and later change the ownership of the server, thus exposing the
> pas
Peter Eisentraut wrote:
On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
--
-- now as untrusted user dblink_regression_test
--
contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
dblink_connect
OK
(1 row)
I think you want some permission checking on fdtest
Peter Eisentraut wrote:
> On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
>> contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
>> dblink_connect
>>
>> OK
>> (1 row)
>
> I think you want some permission checking on fdtest then, right?
>
The proposed "conne
Tom Lane wrote:
> Peter Eisentraut writes:
>> I think you want some permission checking on fdtest then, right?
>
> What about the permissions on the system catalogs themselves?
> AFAICT, the pg_user_mappings view will expose user passwords to
> the "owner" of the foreign server, which doesn't see
Peter Eisentraut writes:
> On Tuesday 06 January 2009 19:50:51 Tom Lane wrote:
>> What about the permissions on the system catalogs themselves?
>> AFAICT, the pg_user_mappings view will expose user passwords to
>> the "owner" of the foreign server, which doesn't seem good.
> Well, no one is forci
On Tuesday 06 January 2009 19:50:51 Tom Lane wrote:
> Peter Eisentraut writes:
> > I think you want some permission checking on fdtest then, right?
>
> What about the permissions on the system catalogs themselves?
> AFAICT, the pg_user_mappings view will expose user passwords to
> the "owner" of t
Peter Eisentraut writes:
> I think you want some permission checking on fdtest then, right?
What about the permissions on the system catalogs themselves?
AFAICT, the pg_user_mappings view will expose user passwords to
the "owner" of the foreign server, which doesn't seem good.
On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
> --
> -- now as untrusted user dblink_regression_test
> --
> contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
> dblink_connect
>
> OK
> (1 row)
I think you want some permission checking on fdtest then, right
Peter Eisentraut wrote:
Joe Conway wrote:
I'm mainly concerned about re-opening security holes that we spent a
lot of time debating and subsequently closing. I suspect if we assume
that any FDW-derived connect string can bypass the checks we put in
place, we will regret it later. But I'm open
Joe Conway wrote:
> I'm mainly concerned about re-opening security holes that we spent a lot
> of time debating and subsequently closing. I suspect if we assume that
> any FDW-derived connect string can bypass the checks we put in place, we
> will regret it later. But I'm open to arguments on both
Joe Conway wrote:
I'm mainly concerned about re-opening security holes that we spent a lot
of time debating and subsequently closing. I suspect if we assume that
any FDW-derived connect string can bypass the checks we put in place, we
will regret it later. But I'm open to arguments on both side
(changed the subject to hopefully get a few more eyes looking at this
thread)
Martin Pihlak wrote:
I'd vote for allowing aribitrary connect strings -- ordinary users cannot
create servers and user mappings unless explicitly granted the privileges.
It probably should be noted in the documentati
14 matches
Mail list logo
