Żeby uzyskać dostęp do PostgreSQL, to należy mieć dostęp do tzw. Login role (dawniej user). Jeśli taka rola jest oznaczona jako superuser, to ta rola uzyskuje nieograniczone uprawnienia do serwera bazy danych. Podczas instalacji serwera, taka rola jest tworzona automatycznie i nazywa się postgres. Role mogą też służyć do nadawania uprawnień nie nadając bezpośrednio dostępu do serwera. Role można w sobie zagnieżdżać. Rola, której członkiem są inne role nosi nazwę group role, a jeśli ta rola pozwala też na korzystanie z serwera to jest to group login name. W sumie logiczne 😊
Poniższa komenda tworzy rolę camila z dodatkowym uprawnieniem do tworzenia nowych baz danych
CREATE ROLE camila LOGIN PASSWORD 'Passw0rd’ VALID UNTIL 'infinity’ CREATEDB;
Słowo superuser dodane na końcu polecenia powoduje, że użytkownik staje się pełnoprawnym i „wszechmocnym” administratorem
CREATE ROLE adm_dagmara LOGIN PASSWORD 'P@ssw0rd’ VALID UNTIL '2030-01-01 00:00′ SUPERUSER;
Jeśli rola nie ma służyć do logowania, to należy opuścić słowo LOGIN. Dodane tutaj INHERIT powoduje, że inne role dodane jako członkowie do toli adm_security będą dziedziczyć jej uprawnienia. Ta opcja jest w zasadzie domyślna, więc nie trzeba jej wpisywać jawnie.
CREATE ROLE adm_security INHERIT;
Grant pozwala dodać jedną rolę do innej roli jako członka. W ten sposób camila otrzyma wszystkie przywileje roli adm_security (bez ewentualnego przywileju superuser, bo ten jako jedyny nie podlega dziedziczeniu)
GRANT adm_security TO camila;
Do nadawania przywilejów dla ról należy posłużyć się poleceniem ALTER ROLE
ALTER ROLE adm_security SUPERUSER;
Kiedy użytkownik należy do roli, to może się przełączyć w tą rolę korzystając z SET ROLE
SET ROLE adm_security;
Po wykonaniu takich przełączeń można na bieżąco sprawdzać w jakiej tożsamości w danej chwili się pracuje. Stąd też można odwołać się do zmiennych session_user i current_user. Session_user określa nazwę roli jaka została wykorzystana do początkowego połączenia do serwera, zaś current_user to nazwa tożsamości w jakiej w danej chwili znajduje się użytkownik
SELECT session_user, current_user;
Dodatkowo superuser ma prawo wykonywać polecenie SET SESSION AUTHORIZATION, które zmieni nawet wpis dotyczący roli używanej na początku do zainicjowania połączenia
SET SESSION AUTHORIZATION ROLE adm_security;
Poprzez przełączanie się miedzy rolami może dojść do… przekrętów. Camila będąc członkiem roli adm_security może zmienić swoją rolę na adm_security. Niestety nie dziedziczy w ten sposób przywileju superuser. Jednak rola adm_security ma przywilej superuser, więc może teraz zmienić swoje konto camila nadając mu uprawnienie superuser. Od tej pory może już robić wszystko!
