Jak utworzyć użytkownika i nadać mu prawa w PostgreSQL

PostgreSQL

Jak utworzyć użytkownika i nadać mu prawa w PostgreSQL

W skrócie

Założenie użytkownika w PostgreSQL wydaje się jednym poleceniem, ale między utworzeniem konta a możliwością realnej pracy jest kilka niezależnych kroków. Nowy użytkownik potrafi się zalogować i mimo to nie widzieć ani jednej tabeli, bo prawo logowania to nie to samo co uprawnienia do danych. Pokażemy Ci, jak utworzyć rolę, nadać jej właściwe prawa warstwa po warstwie i jak sprawdzić, że wszystko działa. Temat jest dla każdego, kto zarządza dostępem do bazy.

Jak to wygląda w praktyce

Tworzysz konto dla nowej osoby albo dla aplikacji i zaczynają się schody. Czasem użytkownik w ogóle nie może się zalogować, bo dostaje odmowę uwierzytelnienia. Innym razem loguje się, ale po wejściu do bazy każde zapytanie kończy się błędem o braku uprawnień do tabeli albo o braku dostępu do schematu. Bywa, że widzi jedne tabele, a innych nie, albo może czytać, lecz nie może zapisywać. Zdarza się też, że po dodaniu nowej tabeli okazuje się, iż użytkownik znów jej nie widzi, mimo że wcześniej nadałeś mu prawa do pozostałych. Wspólny objaw to rozjazd między istnieniem konta a możliwością korzystania z danych.

Dlaczego tak się dzieje

W PostgreSQL nie ma osobnego bytu użytkownika i osobnego bytu grupy, jest jeden mechanizm roli. Rola może mieć prawo logowania i wtedy pełni funkcję użytkownika, albo go nie mieć i wtedy służy jako grupa uprawnień. To dlatego samo utworzenie roli bez prawa logowania nie pozwala się zalogować. Kolejna warstwa to hasło i metoda uwierzytelniania z pliku pg_hba.conf, bo bez ustawionego hasła logowanie metodą hasłową się nie uda. Nawet po udanym logowaniu użytkownik potrzebuje prawa łączenia się z konkretną bazą oraz prawa używania schematu, w którym leżą tabele. Osobno nadaje się uprawnienia do samych obiektów, czyli prawo czytania, wstawiania czy modyfikowania w danej tabeli. Od PostgreSQL 15 zwykli użytkownicy nie mają domyślnie prawa tworzenia obiektów w schemacie public, co dodatkowo zmienia zachowanie względem starszych wersji. Wreszcie uprawnienia nadane dziś obejmują tylko obiekty, które już istnieją, więc tabele utworzone później nie są nimi objęte, chyba że ustawisz uprawnienia domyślne.

Jak to rozwiązać krok po kroku

1. Utwórz rolę z prawem logowania i hasłem: CREATE ROLE nazwa LOGIN PASSWORD 'haslo';. Tak powstaje pełnoprawny użytkownik, który może się zalogować.
2. Nadaj prawo połączenia z bazą: GRANT CONNECT ON DATABASE nazwa_bazy TO nazwa;. Bez tego użytkownik nie wejdzie do właściwej bazy.
3. Nadaj prawo używania schematu, w którym są dane: GRANT USAGE ON SCHEMA nazwa_schematu TO nazwa;. Bez dostępu do schematu tabele pozostaną niewidoczne.
4. Nadaj uprawnienia do obiektów. Aby dać prawo odczytu i zapisu do istniejących tabel w schemacie, użyj GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA nazwa_schematu TO nazwa;. Dobierz zestaw praw do potrzeb konta.
5. Zadbaj o przyszłe tabele przez uprawnienia domyślne: ALTER DEFAULT PRIVILEGES IN SCHEMA nazwa_schematu GRANT SELECT ON TABLES TO nazwa;. Dzięki temu nowe tabele od razu będą objęte prawem, bez ręcznego dogrywania.
6. Przy wielu użytkownikach nie nadawaj praw każdemu z osobna. Utwórz rolę grupującą bez prawa logowania, nadaj uprawnienia jej, a użytkowników dołączaj przez GRANT nazwa_grupy TO nazwa_uzytkownika;. Utrzymanie stanie się prostsze.

Jak sprawdzić, że zadziałało

Najprostszy sprawdzian to zalogować się nowym kontem przez psql i wykonać zapytanie do przykładowej tabeli, na przykład SELECT * FROM schemat.tabela LIMIT 1;. Jeśli zwraca wynik, dostęp działa na całej ścieżce od logowania po odczyt danych. Listę ról i ich atrybutów, w tym prawo logowania, zobaczysz w psql poleceniem \du. Uprawnienia nadane na tabelach obejrzysz poleceniem \dp dla schematu, gdzie widać, która rola ma jakie prawa do których obiektów. Aby potwierdzić uprawnienia domyślne dla przyszłych tabel, utwórz testową tabelę i sprawdź, czy użytkownik od razu ją widzi. Gdy logowanie się nie udaje, wróć do prawa LOGIN i ustawionego hasła, a gdy brak dostępu do danych, sprawdź kolejno prawo do bazy, do schematu i do obiektu.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5