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
Joe Conway wrote:
>> Two specific questions on this approach:
>> 1. This implies that the exact same dblink_connstr_check() is performed
>>on a predefined foreign server and user mapping as a raw connstr --
>>is this desireable? I'm not entirely clear on the intended purpose
>>and use o
Joe Conway wrote:
Peter Eisentraut wrote:
Martin had sent some code for that with his original patch series. I
or someone can review that next.
Here is what I would propose (still needs documentation and regression
test changes, but wanted feedback first). I think it is better to keep
the c
Peter Eisentraut wrote:
On Saturday 20 December 2008 19:33:17 Tom Lane wrote:
Peter wrote:
SQL/MED catalog manipulation facilities
This doesn't do any remote or external things yet, but it gives modules
like plproxy and dblink a standardized and future-proof system for
managing their connectio
On Saturday 20 December 2008 19:33:17 Tom Lane wrote:
> Peter wrote:
> > SQL/MED catalog manipulation facilities
> >
> > This doesn't do any remote or external things yet, but it gives modules
> > like plproxy and dblink a standardized and future-proof system for
> > managing their connection infor
Joe Conway writes:
> Tom Lane wrote:
>> It seems this is a pile of pretty useless code, so far as the core
>> distribution is concerned, unless somebody fixes dblink to use it.
>> Is that on anyone's radar for 8.4?
> How much time is left to get it done? I might be able to find some time
> on th
Tom Lane wrote:
Peter wrote:
SQL/MED catalog manipulation facilities
This doesn't do any remote or external things yet, but it gives modules
like plproxy and dblink a standardized and future-proof system for
managing their connection information.
It seems this is a pile of pretty useless code
Peter wrote:
> SQL/MED catalog manipulation facilities
>
> This doesn't do any remote or external things yet, but it gives modules
> like plproxy and dblink a standardized and future-proof system for
> managing their connection information.
It seems this is a pile of pretty useless code, so far a
21 matches
Mail list logo
