We got a Postgres database credentials (with SSL on) from our contractor, which allow us to connect to the DB using pdAdmin 3. The DB is read-only (can't do pg_dump) to us and basically the contractor will not grant us more privileges.
We need to fetch some data from this remote DB to our local DB. So I wanted to use dblink to perform this task.
I run this on psql:
insert into shifts select * from dblink('hostaddr=remote_addr port=9000 dbname=production user=user password=passwd', 'select user_id, location_id from shifts') as t1(user_id integer, location_id integer);
Then I got:
ERROR: password is required DETAIL: Non-superuser cannot connect if
the server does not request a password. HINT: Target server's
authentication method must be changed.
Since I am new to Postgres and dblink, I have no idea why it is complaining there is no password. And I wonder, to do a dblink connection, does the remote database needs to grant any more privileges?
If the pdAdmin 3 is able to connect to the remote DB with the credentials, what should I do to make dblink work?
Thanks!
Yes only superuser can provide you to the facility to connect through DBLINK
just run this command below whether you are able to connect to database
SELECT dblink_connect('myconn', 'dbname=postgres');
SELECT dblink_connect('myconn', 'hostaddr=remote_addr port=9000 dbname=production user=user password=passwd');
just give the name of database u want to connect after dbname
You can connect
dblink_connect_u
dblink_connect_u() is identical to dblink_connect(), except that it
will allow non-superusers to connect using any authentication method.
Link on postgres site is
dblink
For Superuser ask them to create extension
CREATE EXTENSION dblink;
for your database or schema .
Related
I'm really stuck with the following problem.
At GCloud SQL I have a running postgres' instance.
That instance contains two databases. From one database (source_db) I want to access to another database's (another_db) table (foreign_table) using postgres_fdw extension. The recipe I'm employing currently is this:
1)
CREATE EXTENSION postgres_fdw;
CREATE SERVER foreign_db
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname 'another_db', port '5432', host '<A_PRIVATE_IP>');
CREATE USER MAPPING for guest
SERVER foreign_db
OPTIONS (user 'guest', password 's3cr3t');
CREATE FOREIGN TABLE foreign_table
(
// columns descripions
)
SERVER foreign_db OPTIONS (table_name 'foreign_table');
-- Alternatively I also tried with
CREATE SCHEMA external;
IMPORT FOREIGN SCHEMA public from SERVER foreign_db into external;
GRANT SELECT ON TABLE foreign_table TO guest;
The above commands runs without error, but when I tried to actually access the table I got this:
If using "external" schema
source_db=> select 1 from external.foreign_table limit 1;
ERROR: permission denied for relation foreign_table
CONTEXT: Remote SQL command: SELECT NULL FROM public.foreign_table (*)
If not using "external" schema
source_db=> select 1 from foreign_table limit 1;
ERROR: permission denied for relation foreign_table
CONTEXT: Remote SQL command: SELECT NULL FROM public.foreign_table
The only thing that smells a little is that the error message (at *) displays "public.foreign_table" instead of "external.foreign_table" even when I'm using external schema... but i don't know is that actually means something :S
As far I researched there is no way to login into the posgres instance as a superuser as that is not allowed by the Gcloud's SQL services neither a way to edit the pg_hba.conf file in order to adjust client's authentication affairs.
I searched in a lot of places but without finding what i can do to sort this out. Among the sites and pages i looked are the below list
The official documentation
A personal blog's post
This other SO post having a related issue
This post and this other post regarding permissions and authorizations.
A Nice tutorial about authentication and authorization
P.S.
I was able to make this on a postgres' instance that i ran locally.
User guest on the remote server doesn't have permissions to SELECT from the table. Since the query on the remote server is executed as user guest, you get an error.
GRANT the SELECT privilege on the table on the remote server to the user.
I set up a connection to a foreign db using dblink_connect according to the docs:
CREATE SERVER fdtest FOREIGN DATA WRAPPER dblink_fdw OPTIONS (hostaddr '127.0.0.1', dbname 'foreign_test_db');
CREATE USER test_user WITH PASSWORD 'secret';
CREATE USER MAPPING FOR test_user SERVER fdtest OPTIONS (user 'test_user', password 'secret');
GRANT USAGE ON FOREIGN SERVER fdtest TO regress_dblink_user;
GRANT SELECT ON TABLE foo TO test_user;
\c - regress_dblink_user
SELECT dblink_connect('myconn', 'fdtest');
SELECT * FROM dblink('myconn','SELECT * FROM foo') AS t(a int, b text, c text[]);
The final 'GRANT SELECT' appears to infer that if it is meant to grant select permissions to local user test_user to the table foo on the fdtest foreign data wrapper. However, how I would interpret this command is that it is granting permissions to test_user to select on local table foo (which does not exist). As expected, when I run this command I get an error:
ERROR: relation "foo" does not exist
I would love to know how to actually accomplish this. I would like to be able to restrict local users to only access certain tables from a foreign data wrapper.
You'll have to connect to the remote database and run the GRANT statement there.
Of course you could do that via dblink, but then you'd have to connect with a superuser or the owner of the table.
The connection they show is a loop back connection, it just connects back to the same server and (apparently) database you are already in. This is useful for testing purposes. So granting the permission on the local server is the same thing as granting it on the remote server, as they are the same server.
They do not show the creation of the table, you can find it in the regression test contrib/dblink/sql/dblink.sql (from which the example in the doc derives) as:
CREATE TABLE foo(f1 int, f2 text, f3 text[], primary key (f1,f2));
Extracted code from documentation,
create table sales_catalog(
item_id varchar(10) not null primary key,
item_name_desc varchar(50) not null,
item_desc varchar(50));
Error after using SYSDBA as the user in Firebird SQL3.
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
CREATE TABLE SALES_CATALOG failed
There is no privilege for this operation.
I did some experimenting, and the problem seems to be that if you connect to a database using ISQL without specifying a host name, it will use Firebird embedded to connect to the database (previous versions of Firebird didn't do that on Windows).
Firebird embedded does not require a username and password as it assumes that if you have direct read/write access to the database, that you are allowed to connect to it.
When you connect without specifying a username and password (eg using connect 'database.fdb' instead of connect 'database.fdb' user sysdba, Firebird embedded will use your OS username to connect.
This can be checked because ISQL reports the username when connecting:
SQL> connect 'd:\data\db\fb3\dbofnormal.fdb';
Database: 'd:\data\db\fb3\dbofnormal.fdb', User: MARK
Firebird 3 added new metadata privileges, for example creating a table in a database now requires that you are either the owner of the database (the username used in the create database statement), sysdba (or another admin user), or that you have the create table privilege. See also User Privileges for Metadata Changes. In earlier version any user would be allowed to create tables once they had access to the database.
Now on to the problem: the user (in my example MARK), does not have the create table privilege, so attempting to do so will fail:
SQL> create table testmark ( id integer generated by default as identity primary key);
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-CREATE TABLE TESTMARK failed
-There is no privilege for this operation
There are a few ways to solve this:
Specify a user with sufficient privileges in the connect statement (eg sysdba):
connect 'database.fdb' user sysdba;
Include the host name in the connect statement to connect through Firebird server instead of Firebird embedded, so that you are required to specify user name and password:
connect 'localhost:database.fdb' user sysdba password 'masterkey';
Connect once to your database as sysdba (see first item), and give the necessary privileges to the user (in my case mark):
grant create table to user mark;
From this moment forward this user can create tables (you may need to grant additional privileges, eg create view, create procedure, etc).
I've just set up Postgres for use by different users on my network. Every user has his own username/password/database, but when I connect to Pg I can also see a 'postgres' database (and even create tables etc). I tried to REVOKE access to that database from public but then it won't let me connect. What exactly is the postgres database and why is it needed? Can I disable it so that users only see the database(s) I've created for them?
The postgres database is created by default when you run initdb.
Quote from the manual:
Creating a database cluster consists of creating the directories in which the database data will live (...) creating the template1 and postgres databases. When you later create a new database, everything in the template1 database is copied. (...) The postgres database is a default database meant for use by users, utilities and third party applications.
There is nothing special about it, and if you don't need it, you can drop it:
drop database postgres;
You need to do that as a superuser of course. The only downside of this is that when you run psql as the postgres operating system user, you need to explicitly provide a database name to connect to
If you drop the postgres database you'll find a few things to be confusing. Most tools default to using it as the default database to connect to, for one thing. Also, anything run under the postgres user will by default expect to connect to the postgres database.
Rather than dropping it, REVOKE the default connect right to it.
REVOKE connect ON DATABASE postgres FROM public;
The superuser (usually postgres), and any users you explicitly grant rights to access the database can still use it as a convenience DB to connect to. But others can't.
To grant connect rights to a user, simply:
GRANT connect ON DATABASE postgres TO myuser;
I want to do some cross database references in my application. Briefly, i have two databases called meta and op. I want to do some select query from meta to a table in op database like below but getting the below error. I tried with password and without password. by the way caixa user is a non-super user and my target server (op db server is having MD5 authentication mode.)
meta=> select * from dblink('dbname=op password=caixa','SELECT op_col from op_table') AS t(op_col varchar);
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
What the HINT in the above error message suggests? do i need to change the server's auth mode? Without changing the server's auth mode (MD5) can't i run the above query?
From documentation:
Only superusers may use dblink_connect to create
non-password-authenticated connections. If non-superusers need this
capability, use dblink_connect_u instead.
and
dblink_connect_u() is identical to dblink_connect(), except that it
will allow non-superusers to connect using any authentication method.
That means your dblink call is using dblink_connect implicitly. Use dblink_connect_u instead or change your auth method to e.g. md5.
Note that you also need grant execute privilege to caixa role, for example by:
GRANT EXECUTE ON FUNCTION dblink_connect_u(text) TO caixa;
GRANT EXECUTE ON FUNCTION dblink_connect_u(text, text) TO caixa;
Working example (after GRANT):
meta=> SELECT dblink_connect_u('conn1', 'dbname=op');
meta=> SELECT * FROM dblink('conn1','SELECT op_col from op_table')
AS t(op_col varchar);
op_col
--------
aaa
bbb
ccc
(3 rows)
meta=> SELECT dblink_disconnect('conn1');
EDIT:
Sorry for slightly misleading answer. Of course you don't need dblink_connect_u for md5 authenticated
connection. There is one possibility I see. PostgreSQL has two different connection types: host and local.
Running:
psql -h localhost ..
incorporates host connection, but
dblink_connect('mycon','dbname=vchitta_op user=caixa password=caixa');
uses local type, so if you have non-password method for local connection (for example ident method or trust), then it returns
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
Check
dblink_connect('mycon','hostaddr=127.0.0.1 dbname=vchitta_op user=caixa password=caixa')
for host connection. For clarity if possible please post your pg_hba.conf.
I also checked what about CONNECT privilege on vchitta_op DB, but error message is different:
REVOKE CONNECT ON DATABASE vchitta_op FROM PUBLIC;
REVOKE CONNECT ON DATABASE vchitta_op FROM caixa;
SELECT dblink_connect('mycon','dbname=vchitta_op user=caixa password=caixa');
ERROR: could not establish connection
DETAIL: FATAL: permission denied for database "vchitta_op"
DETAIL: User does not have CONNECT privilege.
There's a workaround that did the trick for me. Non-superusers can execute functions with privileges of a superuser if "SECURITY DEFINER" option is set.
( http://www.postgresql.org/docs/9.1/static/sql-createfunction.html )
That means you can create a function (with superuser owner and SECURITY DEFINER option) that does cross-database manipulation (using dblink() without password) and execute it under non-superuser
I have a similar but a different issue. I have two servers with identical postgres.conf and pg_hba.conf. However one on version 9.2.3 and one on 9.2.4
9.2.3
pg_hba.conf has
local all dblinkuser trust
then I connect to database using any ordinary user
theater_map=# select dblink_connect('dbname=TheaterDB user=dblinkuser password=dbl123');
dblink_connect
----------------
OK
(1 row)
success in connection.
9.2.4
my pg_hba.conf has the same entry as above
theater_map=> select dblink_connect('dbname=TheaterDB user=dblinkuser password=dbl123');
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
NOW
I change my pg_hba.conf on 9.2.4 as below
local all dblinkuser md5
and restart postgres
theater_map=> select dblink_connect('dbname=TheaterDB user=dblinkuser password=dbl123');
dblink_connect
----------------
OK
(1 row)
I Checked the change log between versions 9.2.3 and 9.2.4 but could not find any details.
note: changing auth method from trust to md5 on 9.2.3 does not make any difference and still works.
I found this question googling for same error message, though I use fdw extension rather than db_link. Following steps helped to fix my problem:
find user has no password and set it on - alter user myuser with password 'mypassword'
find authentication method is trust and set it to md5 - vim /var/lib/postgresql/data_/pg_hba.conf
reload pg_hba.conf - SELECT pg_reload_conf(); from psql (log out and log in to verify password is required)
(optionally try access from remote machine, db browser etc.)
setup foreign server and its user mapping - CREATE USER MAPPING FOR CURRENT_USER SERVER myserver OPTIONS (user 'myuser', password 'mypassword');
PostgreSQL 11.10
SELECT ext.column1 from
dblink('hostaddr=192.192.192.192 dbname=yourDbname user=yourUsername password=yourpass',
'select a."column1" from "Table1" a where a."column2"=2')
as ext(column1 text)