Utworzony użytkownik może uzyskać dostęp do wszystkich baz danych w PostgreSQL bez żadnych dotacji

44

Coś mi brakuje, jeśli chodzi o konfigurację PostgreSQL. Chciałbym utworzyć wiele baz danych i użytkowników, którzy są od siebie odizolowani, aby określony użytkownik miał dostęp tylko do baz danych, które wskazałem. Jednak z tego, co mogę ustalić, każdy utworzony użytkownik ma dostęp do wszystkich baz danych bez żadnych konkretnych dotacji.

Oto, co robię na Ubuntu Server 12.04:

apt-get install postgresql
sudo -u postgres createuser -DRSP mike1 (Podanie hasła dla nowego użytkownika)
sudo -u postgres utworzoneb danych1
psql -h localhost -U mike1 data1 (Określanie hasła do logowania użytkownika mike1)

Wygląda na to, że nowy użytkownik „mike1” nie ma problemu z połączeniem z bazą danych „data1” i tworzeniem tabel itp. I to bez uruchamiania jakiejkolwiek komendy GRANT (a właścicielem „data1” jest „postgres”, ponieważ nie określiłem właściciel w kroku 3). Czy to naprawdę tak ma działać?

Chciałbym udzielić mike1 pełnego dostępu do danych1, a następnie powtórzyć to dla większej liczby użytkowników i baz danych, upewniając się, że użytkownicy mają dostęp tylko do jednej (lub kilku) wybranych baz danych.

postgresql permissions

— mikeplate
źródło

1

Należy pamiętać, że nawet jeśli użytkownik jest ograniczony do jednej bazy danych, może nadal sprawdzać tabele globalne, co pozwoli mu zobaczyć listę nazw baz danych i listę użytkowników.

— kgrittn

47

Na poziomie SQL każdy użytkownik może rzeczywiście połączyć się z nowo utworzoną bazą danych, dopóki nie zostanie wydane następujące polecenie SQL:

REVOKE connect ON DATABASE database_name FROM PUBLIC;

Po zakończeniu każdemu użytkownikowi lub roli, która powinna być w stanie się połączyć, należy wyraźnie przyznać uprawnienie do połączenia:

GRANT connect ON DATABASE database_name TO rolename;

Edycja: w scenariuszu z wieloma dzierżawcami connectusunięto by nie tylko uprawnienia. Aby uzyskać porady i najlepsze praktyki najmu, możesz przeczytać na publicznej wiki postgresql: Hosting wspólnej bazy danych i zarządzanie prawami w PostgreSQL .

— Daniel Vérité
źródło

Domyślnie powinno być na odwrót. Chcę utworzyć użytkownika z losowo generowanym hasłem i przyznać mu dostęp do jednego DB, wiedząc, że postgresmoże on uzyskać dostęp do wszystkich baz danych.

— TheRealChx101

24

PUBLIC ma domyślnie dostęp do bazy danych, ale nie ma dostępu do danych. Możesz ODWOŁAĆ PUBLIKĘ:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

Jeśli chcesz mieć to ustawienie dla wszystkich przyszłych baz danych, odwołaj CONNECT w bazie danych template1 (domyślna baza danych szablonów do tworzenia nowej bazy danych):

REVOKE CONNECT ON DATABASE template1 FROM PUBLIC;

— Frank Heikens
źródło

Widzę. Teraz ma to większy sens. Chyba nie powinienem przychodzić tutaj jako nowy użytkownik PostgreSQL i zaprzeczać, że być może PUBLIC nie powinien mieć domyślnie uprawnienia CONNECT na szablonie 1 :) Ale teraz widzę też, że dane nigdy nie były zagrożone. Dzięki!

— mikeplate

1

Jesteś bardzo mile widziany jako nowicjusz, również w przypadku sporów dotyczących ustawień. Każdy może się z tego uczyć!

— Frank Heikens

1

W rzeczywistości to uprawnienie CONNECT nie jest przekazywane z szablonu do nowej bazy danych, więc odwołanie go na szablonie 1 nie ma wspomnianego efektu.

— Daniel Vérité

2

@ DanielVérité Rozumiem. Sądzę więc, że rozwiązaniem jest zawsze pamiętać i wykonać REVOKE CONNECT podczas tworzenia nowej bazy danych. Czy to naprawdę tak robią administratorzy PostgreSQL, czy nie powinienem się tym przejmować, ponieważ dane i tak nie są dostępne? Mimo to uważam, że lista tabel może dawać niepotrzebne informacje na potrzeby przyszłych ataków, jeśli tylko między już autoryzowanymi użytkownikami w środowisku z wieloma dzierżawcami. Ponadto: właśnie zdałem sobie sprawę, że public może również tworzyć własne tabele w dowolnej bazie danych, która nie została REVOKE CONNECT. Muszę powiedzieć, że to trochę dziwne.

— mikeplate

1

Tak. Dodam pokrewne linki do mojej odpowiedzi, możesz przeczytać o tym kilka dodatkowych dokumentów.

— Daniel Vérité

4

Oprócz domyślnego odbierania uprawnień do połączenia z PUBLIC i przyznawania ich zgodnie z konkretnymi potrzebami, drugim poziomem, na którym można kontrolować dostęp, jest plik pg_hba.conf.

Możesz znaleźć miejsce przechowywania pliku za pomocą:

SHOW hba_file;

Jeśli zdecydujesz się skorzystać z tego mechanizmu, zostaną osadzone komentarze, które mogą wystarczyć na rozpoczęcie pracy. Dokumenty są tutaj:

http://www.postgresql.org/docs/current/interactive/auth-pg-hba-conf.html

— kgrittn
źródło

Dzięki! Patrzyłem na plik pg_hba.conf, ale miałem wrażenie, że reguluje on tylko sposób uwierzytelniania użytkownika podczas łączenia się z bazą danych, a nie to, jakie uprawnienia ma użytkownik w tej samej bazie danych.

— mikeplate

1

Użytkownik może łączyć się z bazami danych tylko w sposób dozwolony przez pg_hba.conf. Obejmuje to nie tylko połączenie użytkownika i bazy danych, ale także hosta, z którym się łączą, oraz dozwoloną metodę uwierzytelniania. Jeśli nie potrzebujesz tej szczegółowości kontroli, technika GRANT/ REVOKEomówiona w innych odpowiedziach jest prawdopodobnie łatwiejsza. Po pierwsze potrzebujesz do tego połączenia z bazą danych superużytkownika, w przeciwieństwie do logowania do systemu operacyjnego, aby móc edytować plik.

— kgrittn

0

Natknąłem się na ten wątek, szukając sposobu, aby uniemożliwić użytkownikom nawet wyświetlanie innych nazw baz danych. REVOKE CONNECTNie zapobiec.

Zgodnie z odpowiedziami na to SO pytanie nie ma (godnego polecenia) sposobu na osiągnięcie tego.

— AdamAL
źródło