I have a postgresql (v10) database. I've created database tn_beta_db with schema tn_schema. I've created three users and executed the following, which is meant to grant all of them read and maybe modify access on all tables, current and future that tn_beta_migrator might create.
\c tn_beta_db
-- User tn_beta_reader --
ALTER DEFAULT PRIVILEGES IN SCHEMA tn_schema FOR ROLE tn_beta_reader GRANT SELECT ON TABLES TO tn_beta_reader;
GRANT CONNECT ON DATABASE tn_beta_db TO tn_beta_reader;
GRANT USAGE ON SCHEMA tn_schema TO tn_beta_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA tn_schema TO tn_beta_reader;
-- User tn_beta_migrator --
ALTER DEFAULT PRIVILEGES IN SCHEMA tn_schema FOR ROLE tn_beta_migrator GRANT ALL ON TABLES TO tn_beta_migrator;
GRANT CONNECT ON DATABASE tn_beta_db TO tn_beta_migrator;
GRANT USAGE ON SCHEMA tn_schema TO tn_beta_migrator;
GRANT ALL ON ALL TABLES IN SCHEMA tn_schema TO tn_beta_migrator;
GRANT CREATE ON SCHEMA tn_schema TO tn_beta_migrator;
-- User tn_beta_writer --
ALTER DEFAULT PRIVILEGES IN SCHEMA tn_schema FOR ROLE tn_beta_writer GRANT SELECT,INSERT,DELETE,UPDATE ON TABLES TO tn_beta_writer;
GRANT CONNECT ON DATABASE tn_beta_db TO tn_beta_writer;
GRANT USAGE ON SCHEMA tn_schema TO tn_beta_writer;
GRANT SELECT,INSERT,DELETE,UPDATE ON ALL TABLES IN SCHEMA tn_schema TO tn_beta_writer;
If I now connect as tn_beta_migrator, I can create a table and do things with it.
create table tn_schema.foo(x int);
-- and then INSERT, SELECT, UPDATE, even DROP
But now if I connect as either of tn_beta_reader or tn_beta_writer, I can not use that table.
tn_beta_db=> select * from tn_schema.foo ;
ERROR: permission denied for relation foo
tn_beta_db=>
I would expect to be able to read/write/modify/delete as tn_beta_writer and to be able to read as tn_beta_reader.
If I rerun the grant script, above, this permits me to access foo, but a newly created table bar would then be inaccessible.
I'd thought that the alter default privileges commands would permit these roles, in the future, to access the tables created by tn_beta_migrator.
Any pointers on what I've misunderstood?
The role in the FOR ROLE clause in ALTER DEFAULT PRIVILEGES is not the role that will get the privileges, it is the role that creates the tables.
So your statements should start with
ALTER DEFAULT PRIVILEGES FOR ROLE tn_beta_migrator ...
Related
I am running this command
gcloud sql import sql db1 gs://mybucket/sqldumpfile.gz --database=mydb1
to import a database snapshot into a new database. Before running it, I recreated the same users I had in the source database, using Cloud Console. However, I keep on getting this error:
ERROR: must be member of role "postgres"
STATEMENT: ALTER DEFAULT PRIVILEGES FOR ROLE postgres IN SCHEMA public GRANT SELECT ON TABLES TO user1;
I am not sure what to do and which user must be "member of role postgres".
Any advice is appreciated
To grant default privileges for user2, use the FOR ROLE clause:
ALTER DEFAULT PRIVILEGES FOR USER <user-1> IN SCHEMA <user-1> GRANT INSERT, UPDATE, DELETE ON TABLES TO <user-2>;
ALTER DEFAULT PRIVILEGES FOR USER <user-1> IN SCHEMA <user-1> GRANT SELECT ON TABLES TO <user-2>;
You need to grant the rights from the user-1 which is creating the table, So whenever the user-1 creates a table, it will grant the SELECT rights for the user-2.
For more information refer to this document.
I'm trying to setup a database with a readwrite user jirauser and a readonly user controlling_ro. This is my script to set it up based on this Blog article. testuser is the master user.
PGPASSWORD=XXX psql \
--dbname=postgres \
--host=XXX.XXX.eu-central-1.rds.amazonaws.com \
--port=5432 \
--username=testuser \
<<EOF
-- Clean DB
DROP DATABASE jiradb;
DROP USER jirauser;
DROP USER controlling_ro;
DROP SCHEMA jiraschema;
DROP ROLE readonly;
DROP ROLE readwrite;
-- Create DB
CREATE DATABASE jiradb;
\connect jiradb;
CREATE SCHEMA jiraschema;
-- Revoke privileges from 'public' role
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON DATABASE jiradb FROM PUBLIC;
-- Read-only role
CREATE ROLE readonly;
GRANT CONNECT ON DATABASE jiradb TO readonly;
GRANT USAGE ON SCHEMA jiraschema TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA jiraschema TO readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA jiraschema GRANT SELECT ON TABLES TO readonly;
-- Read/write role
CREATE ROLE readwrite;
GRANT CONNECT ON DATABASE jiradb TO readwrite;
GRANT USAGE, CREATE ON SCHEMA jiraschema TO readwrite;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA jiraschema TO readwrite;
ALTER DEFAULT PRIVILEGES IN SCHEMA jiraschema GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO readwrite;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA jiraschema TO readwrite;
ALTER DEFAULT PRIVILEGES IN SCHEMA jiraschema GRANT USAGE ON SEQUENCES TO readwrite;
-- Users creation
CREATE USER controlling_ro WITH PASSWORD 'XXX';
CREATE USER jirauser WITH PASSWORD 'XXX';
-- Grant privileges to users
GRANT readonly TO controlling_ro;
GRANT readwrite TO jirauser;
EOF
After running this script I expect the roles and the users only to be in the jiradb database. However looking into the default database postgres with dbeaver they are also there. Does this mean they also have access to the postgres database?
That's just an artifact of your client tool.
In reality, PostgreSQL users don't belong to any database; they are shared by all databases. So no matter to which database you are connected when you create a user, it will equally exist for all databases.
You can use the CONNECT permission on the database object or (more typically) configure pg_hba.conf to determine which user can access which database.
According to https://www.postgresql.org/docs/current/sql-createrole.html:
CREATE ROLE adds a new role to a PostgreSQL database cluster. A role is an entity that can own database objects and have database privileges; a role can be considered a “user”, a “group”, or both depending on how it is used. Refer to Chapter 21 and Chapter 20 for information about managing users and authentication. You must have CREATEROLE privilege or be a database superuser to use this command.
Note that roles are defined at the database cluster level, and so are valid in all databases in the cluster.
So it's just your GUI misleading you.
I am setting up a Postgres DB (AWS/RDS) with multiple schemas and want to have granular access control.
Each schema correlates to an application. Typically an application will have a "write" user (INSERT, UPDATE, DELETE etc.), but some applications only needs to read (SELECT) from different schemas.
Inspired by this AWS blog: https://aws.amazon.com/blogs/database/managing-postgresql-users-and-roles/
I face problems with "permission denied" for my readusers querying tables created by writeusers, even though I ALTER DEFAULT PRIVILEGES:
ALTER DEFAULT PRIVILEGES IN SCHEMA someschema GRANT SELECT ON TABLES TO some_read_role;
Steps to reproduce:
Create AWS RDS postgres (10.6) instance with masteruser postgres
(DB postgres) As user postgres:
CREATE DATABASE somedb LC_COLLATE 'da_DK.utf8' LC_CTYPE 'da_DK.utf8' ENCODING 'UTF8' TEMPLATE template0;
(DB somedb) As user postgres:
REVOKE ALL ON DATABASE somedb FROM PUBLIC;
CREATE SCHEMA clients;
CREATE ROLE clients_read_role;
GRANT CONNECT ON DATABASE somedb TO clients_read_role;
CREATE ROLE clients_write_role;
GRANT CONNECT ON DATABASE somedb TO clients_write_role;
GRANT USAGE ON SCHEMA clients TO clients_read_role;
GRANT SELECT ON ALL TABLES IN SCHEMA clients TO clients_read_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA clients GRANT SELECT ON TABLES TO clients_read_role;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA clients TO clients_read_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA clients GRANT SELECT ON SEQUENCES TO clients_read_role;
GRANT USAGE, CREATE ON SCHEMA clients TO clients_write_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA clients TO clients_write_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA clients GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO clients_write_role;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA clients TO clients_write_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA clients GRANT USAGE ON SEQUENCES TO clients_write_role;
(DB somedb) As user postgres:
CREATE USER clients_read WITH PASSWORD 'xxx';
GRANT clients_read_role TO clients_read;
CREATE USER clients_write WITH PASSWORD 'yyy';
GRANT clients_write_role TO clients_write;
(DB somedb) As user clients_write (via LiquiBase):
CREATE TABLE clients.sometable
(
id serial primary key,
name varchar(50) not null
);
(DB somedb) as user clients_read:
SELECT * FROM clients.sometable;
[42501] ERROR: permission denied for relation sometable
From the docs:
You can change default privileges only for objects that will be
created by yourself or by roles that you are a member of.
In other words, running ALTER DEFAULT PRIVILEGES as user postgres only affects tables created by postgres.
To change the defaults for another user's tables, you need to specify which user:
ALTER DEFAULT PRIVILEGES FOR ROLE clients_write ...
Note that the defaults are not inherited, so the target role is clients_write (i.e. the user actually running the CREATE TABLE command, who will become the new table's owner). Defaults for clients_write_role will have no effect unless your users SET ROLE clients_write_role; before creating a table.
Is it possible to alter default priviledges on PostgreSQL role, such that role has SELECT on any table in any schema (existing or created in future)
I have 3 roles (app_r is member of app_rw which is member of app_rwc)
and I am trying this:
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc GRANT USAGE ON SCHEMAS TO app_r;
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc GRANT SELECT ON TABLES TO app_r;
but it does not work.
SELECT has_table_privilege('app_r', 'some_schema.some_table', 'SELECT')
-- false
Is there a way to do this in PG or do I have to use IN SCHEMA and repeat for every schema? (ughhh)
ALTER DEFAULT PRIVILEGES FOR ROLE app_r IN SCHEMA some_schema GRANT SELECT ON TABLES TO app_r;
P.S.
I did try running ALTER DEFAULT before (and after also, just to test) creating schemas and tables...
P.P.S
My role setup is inspired by this answer and I saw in this answer that is not necessary having to explicitly specify schemas
UPDATE #1 - Here is exact role setup I am using:
CREATE ROLE app_rwc INHERIT CREATEDB CREATEROLE;
CREATE ROLE app_rw INHERIT;
CREATE ROLE app_r INHERIT;
GRANT app_r TO app_rw;
GRANT app_rw TO app_rwc;
-- these must be performed *before* any objects are created
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc GRANT USAGE ON SCHEMAS TO app_r;
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc GRANT SELECT ON TABLES TO app_r;
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc GRANT INSERT, UPDATE, DELETE ON TABLES TO app_rw;
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc REVOKE TRUNCATE ON TABLES TO app_rw;
ALTER DEFAULT PRIVILEGES FOR ROLE app_rwc GRANT SELECT, UPDATE ON SEQUENCES TO app_rw;
Is it possible to alter default priviledges on PostgreSQL role, such
that role has SELECT on any table in any schema (existing or created
in future)
As of version 9.6, no.
I have a view called testview in postgresql.
I created a new user called testuser.
I would like testuser to have all privileges on all tables and views in the database.
To do this I ran the following commands:
GRANT ALL PRIVILEGES ON DATABASE testdb TO testuser;
GRANT USAGE ON SCHEMA public TO testuser;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO testuser;
testuser now has access to all tables in the database, but if I try to run SELECT * FROM testview I get the following error: permission denied for relation testview.
What is wrong? How do testuser get access to testview?
I agree it should work. With permissions GRANT ... ON ALL TABLES should include views too.
Did you create the view after granting the privileges to testuser? If so then it doesn't have the same privileges as the other tables. That's because GRANT ... ON ALL TABLES means "on all tables that currently exist". To include tables/views you create in the future, you can say:
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO testuser;
Or if you want to give more than SELECT, you can say ALL PRIVILEGES instead.
I think this behavior of ON ALL TABLES is one of the most misunderstood bits about Postgres permissions, and it isn't really called out in the standard documentation, so I tried to emphasize it in my own Postgres permissions overview.
postgres=# GRANT ALL PRIVILEGES ON DATABASE testdb TO testuser;
postgres=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO testuser;
GRANT USAGE on schema:
GRANT USAGE ON SCHEMA schema_name TO username;
Grant SELECT for a specific table:
GRANT SELECT ON tbl_loans_new TO oloffm;
Grant SELECT for multiple tables:
GRANT SELECT ON ALL TABLES IN SCHEMA schema_name TO username;