permission denied for schema public - zmiany w PostgreSQL 15

PostgreSQL

permission denied for schema public - zmiany w PostgreSQL 15

W skrócie

To jeden z najczęstszych problemów po aktualizacji do PostgreSQL 15 lub nowszego. Kod, który latami działał, nagle nie może utworzyć tabeli w schemacie public. Powód nie jest błędem - twórcy PostgreSQL świadomie zaostrzyli domyślne uprawnienia schematu public, aby ograniczyć ryzyko nadużyć we współdzielonej bazie. Problem dotyczy każdego, kto migruje bazę albo zakłada nową na świeżej wersji. Pokazujemy, co dokładnie się zmieniło i jak przywrócić działanie w kontrolowany sposób.

Jak to wygląda w praktyce

Zwykła rola łączy się z bazą, ale nie może nic w niej utworzyć:

sklep=> CREATE TABLE test (id int);
ERROR:  permission denied for schema public
LINE 1: CREATE TABLE test (id int);
                     ^

Ta sama komenda działała bez zarzutu na PostgreSQL 14 i starszych. Bywa też, że migracja aplikacji (na przykład narzędzie tworzące tabele przy starcie) przewraca się z tym właśnie komunikatem zaraz po podniesieniu wersji serwera.

Zobacz też: Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL

Dlaczego tak się dzieje

Do PostgreSQL 14 schemat public miał nadane prawo CREATE dla specjalnej roli PUBLIC, czyli praktycznie dla każdej roli w bazie. Oznaczało to, że dowolny użytkownik mógł tworzyć obiekty w public - wygodne, ale ryzykowne we współdzielonych bazach. Od wersji 15 to prawo zostało odebrane - schemat public nadal istnieje, ale nie pozwala już domyślnie tworzyć w nim obiektów rolom innym niż właściciel. Dodatkowo właścicielem public jest teraz rola pg_database_owner, czyli właściciel danej bazy. W efekcie rola aplikacji, która wcześniej bez pytania tworzyła tabele, po migracji dostaje odmowę na poziomie schematu, jeszcze zanim dojdzie do samej tabeli.

Jak to rozwiązać krok po kroku

1. Zdecyduj, gdzie aplikacja ma tworzyć obiekty. Wariant zgodny z dawnym zachowaniem: nadaj roli prawo do schematu public: GRANT CREATE, USAGE ON SCHEMA public TO app;.
2. Wariant czystszy i zalecany: załóż osobny schemat dla aplikacji i uczyń rolę jego właścicielem: CREATE SCHEMA sklep_app AUTHORIZATION app;.
3. Ustaw roli search_path, aby domyślnie trafiała do właściwego schematu: ALTER ROLE app SET search_path = sklep_app, public;.
4. Jeśli chcesz przywrócić stare, otwarte zachowanie dla wszystkich ról (świadomie, tylko w zaufanej bazie): GRANT CREATE ON SCHEMA public TO PUBLIC; - używaj tego ostrożnie.
5. Nadaj też prawa do samych danych, jeśli tabele tworzy inna rola niż aplikacja czytająca - patrz przywileje na tabelach (GRANT ... ON ALL TABLES ...).
6. Polecenia GRANT i CREATE SCHEMA wykonuj jako właściciel bazy albo superuser - zwykła rola nie nada sobie sama prawa do schematu.

Jak sprawdzić, że zadziałało

Sprawdź efektywne prawa roli do schematu wprost - obie kolumny powinny zwrócić t:

SELECT has_schema_privilege('app', 'public', 'CREATE') AS moze_tworzyc,
       has_schema_privilege('app', 'public', 'USAGE')  AS moze_uzywac;

Najlepszym testem jest jednak utworzenie tabeli jako rola aplikacji - jeśli CREATE TABLE przejdzie bez odmowy, problem jest rozwiązany. Listę praw schematów obejrzysz też w psql poleceniem \dn+.

Powiązane problemy

• Gdy rola może już tworzyć tabele, a inni użytkownicy nie widzą ich zawartości, sprawdź domyślne uprawnienia, czyli default privileges.
• Zamiast przywracać dawne prawa do public, możesz utworzyć osobne schematy dla aplikacji, co opisujemy w tekście jak organizować schematy w PostgreSQL.
• Komplet uprawnień dla nowego konta aplikacji, od logowania po schemat i tabele, pokazujemy w tekście jak utworzyć użytkownika i nadać mu prawa w PostgreSQL.

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