Det finns några mycket ointuitiva behörighetskrav när du använder REASSIGN
.
Jag har upptäckt att när ett superanvändarkonto inte är tillgängligt (som i fallet med RDS eller Cloud SQL) måste jag tilldela målrollen till min nuvarande roll för att omtilldela eller ta bort ägda objekt från målrollen. Till exempel, om min aktiva användare är postsgres
, och jag försöker ta bort 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
Nu blir det lite knepigare om user_a
råkar vara medlem i postgres
, speciellt om det råkar ärva det medlemskapet genom någon annan roll, låt oss kalla det 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!
Obs:Det finns ett annat allmänt refererat och effektivt svar här:https://sysadmintips.com/services/databases/postgresql-error-permission-denied-to-reassign-objects/ vilket fungerar utmärkt, så länge du kan skapa och logga in som en ny tillfällig användare. Men i vissa sammanhang är det ett problem i sig (och då har du också den extra städningen att hantera att ta bort den tillfälliga rollen när du är klar), så jag försökte undvika det här.