Schlagwort-Archive: Berechtigungen

Der Export von Rollen bei PostgreSQL auf AWS RDS – leider ohne Passwort-Hashes

Schreibe eine Antwort

Ich hatte mir zum Ziel gesetzt, die Daten einer PostgreSQL-RDS zu einer anderen RDS migrieren zu wollen – und das via SQL. Daher habe ich versucht, die Metadaten für die Rollen zu generieren. Normalerweise würde ich das folgendermaßen machen:

$ pg_dumpall -h myrds.eu-central-1.rds.amazonaws.com -U rdsmaster
 -r -f dumpall_roles.sql

Leider klappte das nicht so, weil:

pg_dumpall: error: query failed: ERROR:  permission denied for table pg_authid
pg_dumpall: error: query was: SELECT oid, rolname, rolsuper, rolinherit, rolcreaterole, rolcreatedb, rolcanlogin, rolconnlimit, rolpassword, rolvaliduntil, rolreplication, rolbypassrls, pg_catalog.shobj_description(oid, 'pg_authid') as rolcomment, rolname = current_user AS is_current_user FROM pg_authid WHERE rolname !~ '^pg_' ORDER BY 2

AWS sperrt also den Zugriff auf die Tabelle pg_authid im Catalog. Auch eine Nachfrage beim AWS Support hat mir nur eingeschränkt geholfen.

I would like to kindly inform you that RDS PostgreSQL doesn’t support access on ‘pg_authid’ table. Since RDS is a managed service, for platform stability, RDS don’t support full permission for all system relations. […] The workaround is to supply “–no-role-passwords” to pg_dumpall command.

Na danke. Somit muss ich nun alle Passwörter nachträglich manuell setzen. Klappt natürlich nur, wenn man selbst die Hoheit über die Passwörter hat.

Besonderheit bei der Rollenadministration beim Einsatz von Oracle bei AWS RDS

Schreibe eine Antwort

Bei einem Import eines Datapump-Dumps in eine Oracle-RDS-Umgebung fiel neulich folgende Problematik auf:

Ich hatte eine Rolle, die ich nicht granten konnte und das, obwohl ich mit dem RDS-Master-User arbeite. Es zeigte sich, dass ich keine GRANTs verteilen konnte, weil mir die ADMIN OPTION für diese Rolle fehlte. Leider habe ich die genaue Fehlermeldung nicht mehr parat. Da ich bei RDS auch keine SYS-Privilegien besaß, konnte ich nicht die ADMIN OPTION nachträglich setzen.

Zur Validierung habe ich erneut eine Rolle angelegt und gesehen, dass ich auch automatisch die ADMIN OPTION bei Erstellung erhalte.

CREATE ROLE TESTROLE_A NOT IDENTIFIED;

-- Grantees of TESTROLE_A
GRANT TESTROLE_A TO DB_ADMIN WITH ADMIN OPTION;

Somit bin ich zum Ergebnis gekommen, dass die Rolle von Datapump leider allgemein ohne einen einzigen Administrator importiert wurde und somit zwar allgemein nutzbar, aber nicht mehr administrierbar ist. Da man bei AWS nicht an die SYS-Privilegien herankommt und zur Modifizierung der Rolle die rdsadmin.rdsadmin_util.grant_sys_object-Prozedur nicht hilfreich ist, blieb mir nichts übrig, als manuell die Rolle zu löschen und erneut anzulegen.