this is happening on newly created Postgres 13 instance on GCP's Cloud SQL.
I would like to disallow users to CONNECT to newly created databases. So I am modifying template database:
REVOKE ALL ON DATABASE template1 FROM public;
Then, I create new Database:
CREATE DATABASE mydb TEMPLATE template1;
Then I am checking CONNECT permissions for existing user:
SELECT datname
FROM pg_database
WHERE has_database_privilege('someuser', datname, 'CONNECT')
datname
---------------
cloudsqladmin
postgres
template0
mydb
So as you can see someuser has CONNECT permission to mydb.
Why is this happening? How can I prevent users to connect to newly created databases?
The permissions on a database are not copied from the template database during CREATE DATABASE. Rather, all new databases have the same default permissions: CONNECT and TEMP for PUBLIC, and all permissions for the owner.
There is no way to change that default, short of modifying the PostgreSQL code.
Related
How can I create a postgres user who has admin access only to one database but cannot inspect or interfere with other databases in the postgres instance? The use case is I'm creating a multitenant application
where each tenant gets his own database in the postgresql instance and can create schemas, tables etc and
perhaps use a few pg_tables to inspect his own database but not others.
cannot change the name of the database as it's controlled by me
EDIT: Added more constraints
That's fairly trivial:
CREATE DATABASE newdb;
GRANT CREATE ON DATABASE newdb TO newdba;
Add pg_hba.conf entries to allow newdba to connect to newdb only.
I'm trying to use the timescaledb extension, and so I'm running their official docker image.
In the last line of my docker entrypoint file, I run:
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
I verify that it's available for use with \dx in psql. As soon as I try to make use of the extension, I get:
No function matches the given name and argument types. You might need to add explicit type casts.
I find I have to add it manually by execing into psql and running CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
What's wrong with my entrypoint? Why do I have to manually create the extension after the container is built and running?
Edit: here's the full entrypoint script:
#!/bin/bash
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-EOSQL
CREATE USER test_user PASSWORD 'password123';
ALTER USER test_user WITH SUPERUSER; --needed to create timescaledb extension
CREATE DATABASE testdb OWNER test_user;
GRANT ALL PRIVILEGES ON DATABASE testdb TO test_user;
CREATE DATABASE tsdb OWNER test_user;
GRANT ALL PRIVILEGES ON DATABASE tsdb TO test_user;
ALTER USER test_user CREATEDB;
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
EOSQL
Disclaimer: I don't know docker, but this seems only related to Postgres, not Docker itself
create extension will create the extension in database psql is currently connected to. Seeing the script, this is most probably the default database postgres that you connect to.
So the extension will be created in the postgres database, not in the testdb database.
You have two options on how to change that:
1. Use the template1 database
Anything created in the template1 database will automatically be created in every database created afterwards. So if you connect to the template database and run the create extension before creating the test database, the extension will automatically be available:
psql -v ON_ERROR_STOP=1 --dbname=template1 --username "$POSTGRES_USER" <<-EOSQL
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
CREATE USER test_user PASSWORD 'password123';
ALTER USER test_user WITH SUPERUSER; --needed to create timescaledb extension
CREATE DATABASE testdb OWNER test_user;
GRANT ALL PRIVILEGES ON DATABASE testdb TO test_user;
CREATE DATABASE tsdb OWNER test_user;
GRANT ALL PRIVILEGES ON DATABASE tsdb TO test_user;
ALTER USER test_user CREATEDB;
EOSQL
Note that the extension is created before anything else. The actual order isn't that important, the only thing that is important is that it's done before creating a new database.
2. Connect to the newly created database
Switch to the newly created database from within psql before you create the extension using the \connect command in psql
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-EOSQL
CREATE USER test_user PASSWORD 'password123';
ALTER USER test_user WITH SUPERUSER; --needed to create timescaledb extension
CREATE DATABASE testdb OWNER test_user;
GRANT ALL PRIVILEGES ON DATABASE testdb TO test_user;
CREATE DATABASE tsdb OWNER test_user;
GRANT ALL PRIVILEGES ON DATABASE tsdb TO test_user;
ALTER USER test_user CREATEDB;
\connect testdb
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
EOSQL
The main difference between the two methods is that with the first, the extension will be available automatically in all databases that are created in the future. Whereas with the second method it is only available in the testdb
Unrelated, but: the newly created user does not need the superuser privilege as the extension is created using the postgres user, not the newly created one.
To chime in with the prior answer, the TimescaleDB extension is applied per database, so if you run CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE; without first connecting to your desired database with \c yourdatabase it will apply the extension to the default database. See http://docs.timescale.com/v0.9/getting-started/setup for the step-by-step instructions to apply after install.
In Google's SQL Cloud Postgres service, when I create a database via the Web Console for a PostgreSQL instance, it automatically sets the owner of the database's default "public" schema to be cloudsqladmin. It seems I cannot change the ownership:
mydb=> \dn
List of schemas
Name | Owner
--------+---------------
public | cloudsqladmin
(1 row)
mydb=> alter schema public owner to postgres;
ERROR: must be owner of schema public
mydb=> \du
List of roles
Role name | Attributes | Member of
-------------------+------------------------------------------------+---------------------
cloudsqladmin | Superuser, Create role, Create DB, Replication | {}
cloudsqlagent | Create role, Create DB | {cloudsqlsuperuser}
cloudsqlreplica | Replication | {}
cloudsqlsuperuser | Create role, Create DB | {}
pg_signal_backend | Cannot login | {}
postgres | Create role, Create DB | {cloudsqlsuperuser}
mynewuser | Create role, Create DB | {cloudsqlsuperuser}
I also created a "mynewuser" through the web console, and cannot remove the "mynewuser" from the "cloudsqlsuperuser" group:
mydb=> alter group cloudsqlsuperuser drop user mynewuser;
ERROR: "cloudsqlsuperuser" can't be altered
If I wanted to create a database with a public schema that only a new user has access to (and owns), should I be doing this outside of the Google web ui? It seems like any databases I create are owned by cloudsqladmin, and any users I create are those "cloudsqlsuperuser" members. If I wanted to restrict permissions for a user, should I create that user normally via psql and bypass the web ui altogether?
From my experience, you seem to have to bypass the web ui / cli tool entirely.
When you create a database through the cli tool:
gcloud sql databases create DBNAME --instance INSTANCE
It assigns ownership to cloudsqlsuperuser, same as through the gui from the sounds of it.
When I have created a user specifically through the CLI tool:
gcloud sql users create USER 'host' --instance INSTANCE
Those users get the same permissions as cloudsqlsuperuser. In this case, it is possible to alter the ownership of the database. I had success through psql command connecting as the user I wanted to own the database and running:
ALTER DATABASE database OWNER TO user;
However if the user was created via psql (not glcoud cli), then the permission are not the same and the above failed.
I'd be tempted to create your instance, set the 'postgres' users password through the tool, then psql into the instance from there and do everything you need via sql commands. I think the tool does some things very nicely (as does the UI), but its a pain later on.
If anyone knows better, I'd love to hear how you can work with the default gcloud user.
Basically what happens here is that a usual CREATE DATABASE statement seems to create a new database based on the template0 database. This database is owned by cloudsqladmin. A role only Google has access to. When the gcloud or web GUI is used, it executes the following query:
CREATE DATABASE mydb TEMPLATE template1;
For template1 the owner is set to cloudsqlsuperuser a role that gets assigned to the postgres user, and other users created through the GUI.
So if you would like to create a database using sql with the appropriate privileges, just execute the statement above, and your public schema will then be owned by the cloudsqlsuperuser, and can be altered using the default postgres user, or other users created through the web GUI.
Connect to the database mydb by owner user (for exaple, it is mynewuser).
If you want to change the public schema owner, first you should make the user postgres owner of your database mydb:
mydb=> ALTER DATABASE mydb OWNER TO postgres;
After that, you can change the public schema owner:
mydb=> ALTER SCHEMA public OWNER TO postgres;
Besides, to remove your mynewuser from the cloudsqlsuperuser group (role) use:
mydb=> REVOKE cloudsqlsuperuser FROM mynewuser;
Note: The default postgres user in Google Cloud Platform's (GCP) Cloud SQL (PostgreSQL) is not a superuser of the instance. Also, all users created from the GCP web UI have cloudsqlsuperuser role by default, and the following attributes (privileges): CREATEROLE, CREATEDB and LOGIN. They don't have the SUPERUSER or REPLICATION attributes.
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;
A fresh installation of PostgreSQL 9.3 (according to the YUM Installation manual on the PostgreSQL wiki) on CentOS 6 (64-bit) will not grant permissions to any users.
I log in to the postgres user and open psql, then I create a role for my default user:
CREATE ROLE <name> WITH PASSWORD '<password>';
and then try to grant it privileges on the default postgres database:
GRANT ALL ON DATABASE postgres TO <user>;
which gives the expected output, but the user does not have any permissions on postgres.
The output of \dp <user> is quizically empty as well. Additional testing shows that I cannot give any users permissions. However, when I try to drop a role that has been granted these nonexistent permissions, it says
ERROR: role "<user>" cannot be dropped because some objects depend on it
DETAIL: privileges for database postgres
I am at a loss. I did also check to make sure the postgres Linux user has the appropriate file permissions on the PostgreSQL data directory.
Presumably you're expecting too much of GRANT ALL ON DATABASE postgres TO <user>;
ALL in this context means that the command is equivalent to:
GRANT CREATE,CONNECT,TEMPORARY ON DATABASE postgres TO <user>;
And the way you create the ROLE, it cannot login to any database anyway (you can check this with \du).
It could if it was created with:
CREATE ROLE name WITH LOGIN PASSWORD 'pass';
or use ALTER ROLE name WITH LOGIN later on.
Starting from this, to give the user permissions to create objects in the database, other forms of GRANT should be used.