There is role sequence_owner. This is special tech role for working with sequence only.
create role sequence_owner;
GRANT sequence_owner TO administrator;
GRANT USAGE, SELECT, UPDATE ON ALL SEQUENCES IN SCHEMA schema1 TO sequence_owner;
Also there are several users with role administrator: user1,...user42
GRANT administrator TO user1;
GRANT administrator TO user42;
Using user1 I can create sequence:
create sequence schema1.test_sequence;
but I can't change owner to special sequence_owner role
alter sequence schema1.test_sequence owner to sequence_owner;
There is error:
ERROR: permission denied for schema schema1
I don't wont to use:
GRANT CREATE, USAGE ON SCHEMA schema1 to sequence_owner
Because in this case this role sequence_owner will have more priviligies than it must have.
https://www.postgresql.org/docs/11/sql-altersequence.html
It's impossible:
You must own the sequence to use ALTER SEQUENCE. To change a sequence's schema, you must also have CREATE privilege on the new schema. To alter the owner, you must also be a direct or indirect member of the new owning role, and that role must have CREATE privilege on the sequence's schema.
Related
My Postgres DB has a user - "myuser" who has access to everycommand in schema my_schema.
I want to restrict the user to use only basic sequelize commands like Create, Update, Delete, Select. But the user should not be able to Alter the table (in sequelize, he shouldn't be able to do .sync{} operation).
I have already tried doing:
REVOKE ALTER ALL TABLES IN SCHEMA my_schema from myuser
But the above command is giving error!
Commands I have used to create role is:
CREATE ROLE app_readwrite1;
GRANT CONNECT ON DATABASE dvdrental TO app_readwrite1;
GRANT USAGE, CREATE ON SCHEMA app_schema TO app_readwrite1;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app_schema TO app_readwrite1;
ALTER DEFAULT PRIVILEGES IN SCHEMA app_schema GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_readwrite1;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA app_schema TO app_readwrite1;
ALTER DEFAULT PRIVILEGES IN SCHEMA app_schema GRANT USAGE ON SEQUENCES TO app_readwrite1;
After creating role above, I am creating user and assigning him the role.
Still, I can use Model.sync()- basically "ALTER" command along with CRUD operations.
How can I restrict the user from using alter command?
I was trying to delete PostgreSQL user:
DROP USER ryan;
I received this error:
Error in query:
ERROR: role "ryan" cannot be dropped because some objects depend on it
DETAIL: privileges for database mydatabase
I looked for a solution from these threads:
PostgreSQL - how to quickly drop a user with existing privileges
How to drop user in postgres if it has depending objects
Still have the same error.
This happens after I grant all permission to user "ryan" with:
GRANT ALL PRIVILEGES ON DATABASE mydatabase ON SCHEMA public TO ryan;
DROP USER (or DROP ROLE, same thing) cannot proceed while the role still owns anything or has any granted privileges on other objects.
Get rid of all privileges with DROP OWNED (which isn't too obvious from the wording). The manual:
[...] Any privileges granted to the given roles on objects in the current
database and on shared objects (databases, tablespaces) will also be revoked.
So the reliable sequence of commands to drop a role is:
REASSIGN OWNED BY ryan TO postgres; -- or some other trusted role
DROP OWNED BY ryan;
Run both commands in every database of the same cluster where the role owns anything or has any privileges!
And finally:
DROP USER ryan;
REASSIGN OWNED changes ownership for all objects currently owned by the role.
DROP OWNED then only revokes privileges (ownerships out of the way).
Alternatively, you can skip REASSIGN OWNED. Then DROP OWNED will (also) drop all objects owned by the user. (Are you sure?!)
Related:
Drop a role with privileges (with a function to generate commands for all relevant DBs)
Find objects linked to a PostgreSQL role
What worked for me was to follow these steps:
Connecting to the database
\c mydatabase
Reassigning ownership
REASSIGN OWNED BY ryan TO <newuser>;
Or/and just deleting the object
DROP OWNED BY ryan;
Executing REVOKE PRIVILEGES
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM ryan;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM ryan;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public FROM ryan;
Dropping the user
DROP USER ryan;
PS: You might not need to execute both Step 2 and 3, just one of the two steps might be usually enough.
What worked for me on RDS Postgres 13:
REVOKE ALL PRIVILEGES ON DATABASE <my_db> FROM <my_user>;
I also had a similar error where the role was owner for tables so it couldn't be dropped, had to re-assign table owner with:
ALTER TABLE <my_table> OWNER TO <trusted_role>;
Doing a REASSIGN like this didn't work for me on RDS because AWS doesn't give you full superuser to your master user:
REASSIGN OWNED BY <olduser> TO <newuser>;
REVOKE ALL ON SCHEMA "public" FROM "<user>";
Worked for me.
What worked for me was to recreate template1 database and then drop some role:
$ psql -U postgres postgres
postgres=# update pg_database set datistemplate = false where datname='template1';
UPDATE 1
postgres=# drop database template1;
DROP DATABASE
postgres=# create database template1 template=template0;
CREATE DATABASE
postgres=# update pg_database set datistemplate = true where datname='template1';
UPDATE 1
postgres=# DROP ROLE test;
DROP ROLE
For people who use AWS Postgresql RDS, you may try following
login to postgres user, then grant owner
postgres=> GRANT target_user to old_user;
GRANT ROLE
Login to target db using user that would like to remove(old_user), then reassign
target_db=> REASSIGN OWNED BY old_user TO target_user;
REASSIGN OWNED
Login back to postgres user, revoke all privileges then drop user
postgres=> REVOKE ALL PRIVILEGES ON DATABASE target_db FROM old_user;
REVOKE
postgres=> DROP USER old_user;
DROP ROLE
Ref. https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-drop-user-role/
I am using PostgreSQL 10.4 and I found a strange behavior.
If we create an role and grant it to CONNECT the database:
CREATE ROLE dummy;
GRANT CONNECT ON DATABASE test TO dummy;
Then we cannot drop this role, even if it owns no object at all, this command:
DROP ROLE dummy;
Raises:
ERROR: role "dummy" cannot be dropped because some objects depend on it
SQL state: 2BP01
Detail: privileges for database test
Documentation is a bit misleading:
Class 2B — Dependent Privilege Descriptors Still Exist
2B000 dependent_privilege_descriptors_still_exist
2BP01 dependent_objects_still_exist
It says dependent objects still exist, but it seems there are no objects dependent to this specific role, it owns nothing on the database.
Anyway, if we revoke the CONNECT privilege, then role can be dropped:
REVOKE CONNECT ON DATABASE test FROM dummy;
DROP ROLE dummy;
I just checked the behavior also exists on PostgreSQL 9.5. I feel it a bit strange and I cannot understand why this specific privilege makes dropping role fails.
Additional observations
This is really blocking, because we can neither reassign this object:
REASSIGN OWNED BY dummy TO postgres;
Nor drop the object:
DROP OWNED BY dummy;
Both raise related errors:
ERROR: permission denied to reassign objects
SQL state: 42501
ERROR: permission denied to drop objects
SQL state: 42501
As #RaymondNijland pointed out, this must be because the CONNECT privileges is viewed as a role dependent object. The following query:
WITH
R AS (SELECT * FROM pg_roles WHERE rolname = 'dummy')
SELECT
D.*
FROM
R, pg_shdepend AS D
WHERE
refobjid = R.oid;
Returns a single row when CONNECT is granted:
"dbid";"classid";"objid";"objsubid";"refclassid";"refobjid";"deptype"
0;1262;27961;0;1260;27966;"a"
And no row at all when the privilege is revoked. This at least explain why we cannot reassign the object.
About the Dependency Type, the documentation states:
SHARED_DEPENDENCY_ACL (a)
The referenced object (which must be a role) is mentioned in the
ACL (access control list, i.e., privileges list) of the dependent
object. (A SHARED_DEPENDENCY_ACL entry is not made for the owner of
the object, since the owner will have a SHARED_DEPENDENCY_OWNER entry
anyway.)
But I have not enough insight to understand it clearly.
My question are:
Do Postgres always require to revoke privileges before dropping a role?
If not, why this specific privilege behaves like this?
There are some very unintuitive permission requirements when using REASSIGN.
I have found that when a superuser account is not available (as in the case of RDS or Cloud SQL) I have to grant the target role to my current role in order to reassign or drop owned objects from the target role. For instance, if my active user is postsgres, and I'm trying to remove user_a:
> DROP OWNED BY user_a
ERROR: permission denied to drop objects
> GRANT user_a TO postgres;
GRANT ROLE
> DROP OWNED BY user_a;
DROP OWNED
Now, it becomes a little trickier if user_a happens to be a member of postgres, especially if it happens to inherit that membership through some other role, let's call it schema_admin...
> DROP OWNED BY user_a
ERROR: permission denied to drop objects
> GRANT user_a TO postgres;
ERROR: role "user_a" is a member of role "postgres"
-- Alright, let's try to revoke it...
> REVOKE postgres FROM user_a;
REVOKE ROLE
> GRANT user_a TO postgres;
ERROR: role "user_a" is a member of role "postgres"
-- It's still a member through the inherited grant - trying to revoke again doesn't work:
> REVOKE postgres FROM user_a;
WARNING: role "user_a" is not a member of role "postgres"
REVOKE ROLE
-- So you have to identify the role it's inheriting from, and revoke that:
> REVOKE schema_admin FROM user_a;
REVOKE ROLE
> GRANT user_a TO postgres;
GRANT ROLE
-- Now just to be safe, I'll reassign owned objects before actually dropping everything:
> REASSIGN OWNED BY user_a TO postgres;
REASSIGN OWNED
> DROP OWNED BY user_a;
DROP OWNED
> DROP ROLE user_a;
DROP ROLE;
Voila!
Note: There is another widely-referenced and effective answer here: https://sysadmintips.com/services/databases/postgresql-error-permission-denied-to-reassign-objects/ which works great, as long as you are able to create and log in as a new temporary user. However, in some contexts, that is a problem in itself (and then you also have the extra cleanup to handle of removing that temporary role when you're done), so I tried to avoid that here.
Database idd owner is role idd_owner.
Database has 2 data schemas: public and firma1.
User may have directly or indirectly assigned rights in this database and objects.
User is not owner of any object. It has only granted rights.
How to drops such user ?
I tried
revoke all on all tables in schema public,firma1 from "vantaa" cascade;
revoke all on all sequences in schema public,firma1 from "vantaa" cascade;
revoke all on database idd from "vantaa" cascade;
revoke all on all functions in schema public,firma1 from "vantaa" cascade;
revoke all on schema public,firma1 from "vantaa" cascade;
revoke idd_owner from "vantaa" cascade;
ALTER DEFAULT PRIVILEGES IN SCHEMA public,firma1 revoke all ON TABLES from "vantaa";
DROP ROLE if exists "vantaa"
but got error
role "vantaa" cannot be dropped because some objects depend on it
DETAIL: privileges for schema public
DROP ROLE if exists "vantaa"
How to fix this so that user can dropped ?
How to create sql or plpgsql method which takes user name as parameter and drops this user in all cases without dropping data ?
Using Postgres 9.1+
Before dropping the user you can run :
REASSIGN OWNED BY vantaa TO <newuser>
you could just reassign to postgres if you don't know who to reassign that to ...
REASSIGN OWNED BY vantaa TO postgres;
Your reassignment can fail.
When you reassign to a new user/role
- you do it on the currently selected database
- the current user must belong to the 'from' role and 'to' (grant them and revoke them after)
Excerpt of a shell script of mine (a few things omitted)
# The DROP USER operation will fail if this user is the owner of an existing schema, table, index...
# The user creating a resource owns it. It should transfer the ownership to the role
# When reassigning, the current user needs to have the <<roles>> associated to BY and TO to execute the command.
GRANT $_roleservice TO $_superuser;
GRANT $_account TO $_superuser;
REASSIGN OWNED BY $_account TO $_roleservice;
# dropping the user removes it from the current user list of roles/users
DROP USER $_account;
REVOKE $_roleservice FROM $_superuser;
I would like to give a user all the permissions on a database without making it an admin.
The reason why I want to do that is that at the moment DEV and PROD are different DBs on the same cluster so I don't want a user to be able to change production objects but it must be able to change objects on DEV.
I tried:
grant ALL on database MY_DB to group MY_GROUP;
but it doesn't seem to give any permission.
Then I tried:
grant all privileges on schema MY_SCHEMA to group MY_GROUP;
and it seems to give me permission to create objects but not to query\delete objects on that schema that belong to other users
I could go on by giving USAGE permission to the user on MY_SCHEMA but then it would complain about not having permissions on the table ...
So I guess my question is: is there any easy way of giving all the permissions to a user on a DB?
I'm working on PostgreSQL 8.1.23.
All commands must be executed while connected to the right database cluster. Make sure of it.
Roles are objects of the database cluster. All databases of the same cluster share the set of defined roles. Privileges are granted / revoked per database / schema / table etc.
A role needs access to the database, obviously. That's granted to PUBLIC by default. Else:
GRANT CONNECT ON DATABASE my_db TO my_user;
Basic privileges for Postgres 14 or later
Postgres 14 adds the predefined, non-login roles pg_read_all_data / pg_write_all_data.
They have SELECT / INSERT, UPDATE, DELETE privileges for all tables, views, and sequences. Plus USAGE on schemas. We can GRANT membership in these roles:
GRANT pg_read_all_data TO my_user;
GRANT pg_write_all_data TO my_user;
This covers all basic DML commands (but not DDL, and not some special commands like TRUNCATE or the EXECUTE privilege for functions!). The manual:
pg_read_all_data
Read all data (tables, views, sequences), as if having SELECT rights
on those objects, and USAGE rights on all schemas, even without
having it explicitly. This role does not have the role attribute
BYPASSRLS set. If RLS is being used, an administrator may wish to
set BYPASSRLS on roles which this role is GRANTed to.
pg_write_all_data
Write all data (tables, views, sequences), as if having INSERT,
UPDATE, and DELETE rights on those objects, and USAGE rights on
all schemas, even without having it explicitly. This role does not
have the role attribute BYPASSRLS set. If RLS is being used, an
administrator may wish to set BYPASSRLS on roles which this role is
GRANTed to.
All privileges without using predefined roles (any Postgres version)
Commands must be executed while connected to the right database. Make sure of it.
The role needs (at least) the USAGE privilege on the schema. Again, if that's granted to PUBLIC, you are covered. Else:
GRANT USAGE ON SCHEMA public TO my_user;
Or grant USAGE on all custom schemas:
DO
$$
BEGIN
-- RAISE NOTICE '%', ( -- use instead of EXECUTE to see generated commands
EXECUTE (
SELECT string_agg(format('GRANT USAGE ON SCHEMA %I TO my_user', nspname), '; ')
FROM pg_namespace
WHERE nspname <> 'information_schema' -- exclude information schema and ...
AND nspname NOT LIKE 'pg\_%' -- ... system schemas
);
END
$$;
Then, all permissions for all tables (requires Postgres 9.0 or later).
And don't forget sequences (if any):
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO my_user;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO my_user;
Alternatively, you could use the "Grant Wizard" of pgAdmin 4 to work with a GUI.
This covers privileges for existing objects. To also cover future objects, set DEFAULT PRIVILEGES. See:
Grant privileges for a particular database in PostgreSQL
How to manage DEFAULT PRIVILEGES for USERs on a DATABASE vs SCHEMA?
There are some other objects, the manual for GRANT has the complete list. As of Postgres 14:
privileges on a database object (table, column, view, foreign table, sequence, database, foreign-data wrapper, foreign server, function, procedure, procedural language, schema, or tablespace)
But the rest is rarely needed. More details:
Grant privileges for a particular database in PostgreSQL
How to grant all privileges on views to arbitrary user
Consider upgrading to a current version.
GRANT ALL PRIVILEGES ON DATABASE "my_db" to my_user;
In PostgreSQL 9.0+ you would do the following:
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA MY_SCHEMA TO MY_GROUP;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA MY_SCHEMA TO MY_GROUP;
If you want to enable this for newly created relations too, then set the default permissions:
ALTER DEFAULT PRIVILEGES IN SCHEMA MY_SCHEMA
GRANT ALL PRIVILEGES ON TABLES TO MY_GROUP;
ALTER DEFAULT PRIVILEGES IN SCHEMA MY_SCHEMA
GRANT ALL PRIVILEGES ON SEQUENCES TO MY_GROUP;
However, seeing that you use 8.1 you have to code it yourself:
CREATE FUNCTION grant_all_in_schema (schname name, grant_to name) RETURNS integer AS $$
DECLARE
rel RECORD;
BEGIN
FOR rel IN
SELECT c.relname
FROM pg_class c
JOIN pg_namespace s ON c.namespace = s.oid
WHERE s.nspname = schname
LOOP
EXECUTE 'GRANT ALL PRIVILEGES ON ' || quote_ident(schname) || '.' || rel.relname || ' TO ' || quote_ident(grant_to);
END LOOP;
RETURN 1;
END; $$ LANGUAGE plpgsql STRICT;
REVOKE ALL ON FUNCTION grant_all_in_schema(name, name) FROM PUBLIC;
This will set the privileges on all relations: tables, views, indexes, sequences, etc. If you want to restrict that, filter on pg_class.relkind. See the pg_class docs for details.
You should run this function as superuser and as regular as your application requires. An option would be to package this in a cron job that executes every day or every hour.
I did the following to add a role 'eSumit' on PostgreSQL 9.4.15 database and provide all permission to this role :
CREATE ROLE eSumit;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO eSumit;
GRANT ALL PRIVILEGES ON DATABASE "postgres" to eSumit;
ALTER USER eSumit WITH SUPERUSER;
Also checked the pg_table enteries via :
select * from pg_roles;
Database queries snapshot :
In PostgreSQL 12 and later, it is possible to grant all privileges of a table in a database to a role/user/account.
The syntax is:
GRANT ALL ON table_name TO role_name;
If you want to grant it to all tables in the database then the syntax will be:
GRANT ALL ON ALL TABLES TO role_name;
If you want to grant it to all tables of a schema in the database then the syntax will be:
GRANT ALL ON ALL TABLES IN SCHEMA schema_name TO role_name;
Note: Remember you will need to select the database before you can grant its privileges to a user.
Resources: PostgreSQL GRANT
That's all
I hope this helps
GRANT USAGE ON SCHEMA schema_name TO user;
GRANT ALL ON SCHEMA schema_name TO user_name;
Give all permissions to a user on a PostgreSQL database:
Command:
grant all privileges on database [database_name] to [database_user_name];
Example:
grant all privileges on database studentdb to shaifullah;
OR
GRANT ALL PRIVILEGES ON DATABASE studentdb TO shaifullah;