Can't drop user from Redshift

Question

I am trying to drop user form Redshift but it always fails with the same message

user "XXX" cannot be dropped because the user has a privilege on some object;

Following a google search on it I found out that I need to revoke the user's permissions so I run several revoke queries but I still fail with the same message:

The queries I ran:

revoke all on schema YYY from XXX;
revoke usage on schema ZZZ from XXX;
revoke all on database LLL from XXX;

Any idea why I still get this failure message?

Answer 1

Please deploy this view from github "v_get_obj_priv_by_user"

Once done , follow below steps

1. A_user ---User that has to drop

   B_user ---Table ownership of old table need to map to this user.

   If you wish to to change owner of all tables belong to A_user, then

   select schemaname,tablename from pg_tables where tableowner like 'A_user';

   For retrieved above tables run

   alter table schemaname.tablename owner to B_user;

2. Revoke all on schema where A_user has some privileges

   select distinct schemaname from admin.v_get_obj_priv_by_user where usename like 'A_user';

   For retrieved above tables run

   revoke all on schema XXXX from A_user;

3. Revoke all on tables where A_user has some privileges

   select distinct tables from admin.v_get_obj_priv_by_user where usename like 'A_user';

   For retrieved above tables run

   revoke all on all tables in schema XXXX from A_user;

4. Drop user usename;

If there are two database in one cluster, please do this for both databases.

Answer 2

The v_generate_user_grant_revoke_ddl admin view allows you to see existing grants and their corresponding revokes.

With this sql:

SELECT
  ddl
FROM admin.v_generate_user_grant_revoke_ddl
WHERE ddltype = 'revoke'
  AND grantee = '<USERNAME>
  OR grantor = '<USERNAME>')
ORDER BY
  objseq,
  grantseq desc;

I was finally able to find all grants and generate the revoke statements.

Answer 3

After trying suggestions from countless posts and threads, awslabs' aws-redshift-utils provided relief in the form of admin.v_find_dropuser_objs view. It instantly identified the remaining dependencies making it possible to drop the user in question.

Answer 4

already replied here on DBA Stack Exchange.

Before you drop a user, you must revoke any privileges that the user has and then transfer ownership of any database objects that the user owns.

1. Download and install the v_generate_user_grant_revoke_ddl.sql script from the AWS Labs GitHub repository. This script creates a view in Amazon Redshift that is useful for the next two steps.

2. Find all privileges granted to the user and then grant those privileges to the user again, as a superuser or another user, as shown in the following example.

   SELECT regexp_replace(ddl,grantor,'') FROM admin.v_generate_user_grant_revoke_ddl WHERE grantor='' and ddltype='grant' AND objtype <>'default acl' order by objseq,grantseq;

3. Find all privileges granted to the user and then revoke those privileges, as shown in the following example.

   SELECT ddl FROM admin.v_generate_user_grant_revoke_ddl WHERE ddltype='revoke' and (grantee='' OR grantor='') order by objseq, grantseq desc;

4. Download and install the v_find_dropuser_objs.sql script from the AWS Labs GitHub repository. This script creates a view in Amazon Redshift that is useful for the next step.

5. Find all objects owned by the user and then transfer ownership to a different user. In the example below, is the current owner andis the new owner.

6. Repeat steps 2-5 in each database on the cluster.

7. Drop the user.

   DROP USER

Source: https://aws.amazon.com/premiumsupport/knowledge-center/redshift-user-cannot-be-dropped/

Answer 5

Others' answers have been great for untangling this mess of a permissioning system redshift has chosen to employ. However, if, like me, you're a superuser and are getting a permission denied error when trying to alter default privileges in redshift and this is preventing you from dropping a user, be sure to follow @Vince Hill's comment using this sequence:

1. GRANT ALL ON SCHEMA some_schema TO foobar;
2. ALTER DEFAULT PRIVILEGES FOR USER foobar IN SCHEMA some_schema REVOKE ALL ON Tables FROM foobar;
3. REVOKE ALL ON SCHEMA foobar FROM foobar;
4. DROP USER foobar;

I could not understand for the life of me why I, as a superuser who can delete this entire cluster, was getting a permission denied error when trying step 2 without first doing step 1. Absolutely maddening but thankfully resolved.