From: | "Kreißl, Karsten" <KREISSL(at)his(dot)de> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | User Privileges using dblink |
Date: | 2004-06-22 13:15:12 |
Message-ID: | E8AEFF3401E82E4699359F1EBBED6A2101F83BF4@exchange.his.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
we want use dblink to connect several databases in a client/server environment. Connection from local users to the remote databases should be possible only for privileged users. We tried a solution with dblink, embedding this command in a view, like this:
create view inst as select * from dblink('host=pollux port=5432 dbname=cob_int user=his_int password=#integration#', .....
This solution is insecure, because login and password is readable for everyone.
We tried to call dblink without username and login, but it fails,i.e.
create view inst as select * from dblink('host=pollux port=5432 dbname=cob_int', .....
What we are searching for, is a solution which uses the current login information (user and password).
The second problem with dblink is a security hole. If you have a table without any grants for the current user, this user can create a view to circumvent the table privileges, i.e..
Current user is svawork (not a superuser!). Current database is sva4_int1. Table inst has privileges only for a user sva. If user svawork tried to read from inst it fails. This is ok.
If svawork create a view like:
create view myinst as select * from dblink('dbname=sva4_int1','select .... from inst') as (.......);
The view connect not to a remote database. It uses the local database.
You can read the data from table inst without any restrictions! (Select * from myinst ...)
This problem could also be resolved, if dblink uses the current login information.
Any solutions welcome.
Karsten
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2004-06-22 13:32:55 | pgpool 2.0 is available |
Previous Message | Pavel Stehule | 2004-06-22 08:33:23 | Re: PGplSql: Relation 44451 does not exist |