Tworzenie roli poleceniem CREATE ROLE pozwala grupować uprawnienia i przypisywać je zbiorczo użytkownikom.
Rola jako wspólny zestaw uprawnień w PostgreSQL
W PostgreSQL rola jest obiektem bazy danych, który może pełnić funkcję użytkownika, grupy uprawnień albo obu tych funkcji jednocześnie. Rola utworzona poleceniem CREATE ROLE nie otrzymuje automatycznie dostępu do wszystkich tabel, schematów ani baz danych. Samo utworzenie obiektu tworzy tożsamość, której uprawnienia trzeba nadać osobno, zgodnie z wymaganiami konkretnej aplikacji.
Przykładowe polecenie CREATE ROLE ksiegowosc; tworzy rolę o nazwie ksiegowosc. Jeżeli ma ona służyć wyłącznie jako grupa, można przypisywać do niej inne role za pomocą polecenia GRANT ksiegowosc TO anna;. Użytkownik Anna uzyskuje wtedy członkostwo w roli, ale zakres faktycznych uprawnień nadal zależy od praw nadanych roli ksiegowosc oraz od sposobu dziedziczenia tych praw.
Składnia CREATE ROLE i właściwości konta
PostgreSQL pozwala określić właściwości roli już podczas jej tworzenia. Polecenie CREATE ROLE raporty LOGIN PASSWORD 'haslo'; tworzy rolę, która może logować się do serwera, ponieważ zawiera atrybut LOGIN. Bez tego atrybutu rola może być używana jako grupa, lecz nie może bezpośrednio uwierzytelnić się podczas nawiązywania sesji. Do tworzenia ról i zmiany ich atrybutów potrzebne są odpowiednie uprawnienia administracyjne, zwykle wynikające z członkostwa w roli z atrybutem CREATEROLE albo z uprawnień superużytkownika.
Do często używanych atrybutów należą między innymi NOLOGIN, CREATEDB, NOCREATEDB, CREATEROLE, NOCREATEROLE, INHERIT i NOINHERIT. CREATEDB pozwala roli tworzyć bazy danych, a CREATEROLE umożliwia tworzenie ról oraz modyfikowanie części ich właściwości. Atrybut SUPERUSER zapewnia szerokie uprawnienia omijające zwykły model kontroli dostępu, dlatego nie powinien być używany jako zamiennik precyzyjnie nadanych praw. Hasło można ustawić również poleceniem CREATE ROLE aplikacja LOGIN PASSWORD 'tajne_haslo';, jednak rzeczywista możliwość logowania zależy także od konfiguracji uwierzytelniania w pliku pg_hba.conf.
Nadawanie, dziedziczenie i odbieranie praw
Utworzenie roli i nadanie jej członkostwa to dwa różne działania. Uprawnienia do obiektów, takich jak tabela, schemat lub funkcja, nadaje się poleceniem GRANT. Przykład GRANT SELECT, INSERT ON TABLE zamowienia TO ksiegowosc; przyznaje roli ksiegowosc prawo odczytu i dodawania wierszy do tabeli zamowienia. Jeżeli użytkownik jest członkiem tej roli, może korzystać z tych praw zgodnie z zasadami członkostwa i dziedziczenia obowiązującymi w PostgreSQL.
Domyślnie role mają atrybut INHERIT, więc uprawnienia ról, których są członkami, mogą być używane bez każdorazowego przełączania roli. Przy NOINHERIT członkostwo nie powoduje automatycznego użycia odziedziczonych praw; sesja może wymagać polecenia SET ROLE ksiegowosc;, a możliwość takiego przełączenia wynika z członkostwa i jego opcji. Członkostwo można odebrać przez REVOKE ksiegowosc FROM anna;, natomiast uprawnienia obiektowe przez polecenie takie jak REVOKE INSERT ON TABLE zamowienia FROM ksiegowosc;. W PostgreSQL należy również sprawdzać prawa wynikające z właścicielstwa obiektów, członkostwa w innych rolach oraz uprawnień publicznych nadanych specjalnej roli PUBLIC.
Weryfikacja konfiguracji ról podczas serwisowania
Problemy z rolami często ujawniają się jako błędy logowania albo komunikaty o braku uprawnień do tabeli, schematu lub funkcji. Administrator może sprawdzić listę ról w narzędziu psql poleceniem \du, a informacje o członkostwach i atrybutach przeanalizować w katalogu systemowym PostgreSQL. Do sprawdzenia bieżącej tożsamości sesji służą funkcje current_user i session_user. Różnica między nimi może wskazywać, że aplikacja użyła SET ROLE albo działa w kontekście odziedziczonych uprawnień.
Przy diagnostyce należy odtworzyć problem na tym samym koncie, bazie danych i schemacie, z których korzysta aplikacja. Samo sprawdzenie, że rola istnieje, nie potwierdza dostępu do danych. Trzeba zweryfikować między innymi, czy użytkownik ma możliwość połączenia z konkretną bazą, czy posiada USAGE dla schematu oraz odpowiednie prawa dla tabeli. Warto też sprawdzić, czy konto nie ma atrybutu NOLOGIN, czy hasło nie wygasło oraz czy reguły w pg_hba.conf dopuszczają wybraną metodę uwierzytelniania. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w przypadku stanowiska używanego do obsługi PostgreSQL można przygotować środowisko do bezpiecznej weryfikacji klienta, połączenia i komunikatów błędów.
