Postgresql: co robi UDZIELENIE WSZYSTKICH UPRAWNIEŃ NA BAZIE DANYCH?

Próbuję przyznać wszystkie uprawnienia do wszystkich tabel w danej bazie danych nowemu użytkownikowi postgres (nie właścicielowi). Wygląda na to, że GRANT ALL PRIVILEGES ON DATABASE my_db TO new_user;tego nie robi. Po pomyślnym uruchomieniu polecenia (jako użytkownik postgres) otrzymuję następujące polecenie jako nowy użytkownik:

$ psql -d my_db
my_db => SELECT * FROM a_table_in_my_db;
ERROR:  permission denied for relation a_table_in_my_db

Dwa pytania:

1) Co robi powyższe polecenie, jeśli nie udziela wszystkich uprawnień do wszystkich tabel na my_db?

2) Jaki jest właściwy sposób nadania użytkownikowi wszystkich uprawnień do wszystkich tabel? (w tym na wszystkich tabelach utworzonych w przyszłości)

Odpowiedzi na twoje pytania pochodzą z internetowych dokumentów PostgreSQL 8.4 .

1. GRANT ALL PRIVILEGES ON DATABASEprzyznaje CREATE, CONNECT, i TEMPORARYuprawnienia bazy danych do roli (użytkownicy są odpowiednio nazywane ról ). Żadne z tych uprawnień w rzeczywistości nie zezwala roli na odczyt danych z tabeli; SELECTwymagane są do tego uprawnienia na stole.

2. Nie jestem pewien, czy istnieje „właściwy” sposób nadania roli wszystkim uprawnieniom na wszystkich stołach. Najlepszym sposobem zapewnienia, że ​​dana rola ma wszystkie uprawnienia na stole, jest upewnienie się, że rola jest właścicielem stołu. Domyślnie każdy nowo utworzony obiekt jest własnością roli, która go utworzyła, więc jeśli chcesz, aby rola miała wszystkie uprawnienia na stole, użyj tej roli, aby go utworzyć.

   PostgreSQL 9.0 wprowadza następującą składnię, która jest prawie taka, jak chcesz:

   GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO new_user;

   Nacisk polega na tym, że jeśli tworzysz tabele w schematach poza domyślnym schematem „publicznym”, GRANTnie będzie to miało zastosowania. Jeśli korzystasz ze schematów niepublicznych, będziesz mieć GRANTosobne uprawnienia do tych schematów.

Możliwe jest skonfigurowanie wielu loginów do działania jako właściciel bazy danych:

• Utwórz rolę „nologin”, aby działać jako właściciel: create role dbowner nologin
• Zmień właściciela swojej bazy danych na: alter database mydb owner dbowner
• Nadaj wszystkim loginom nową rolę: grant dbowner to user1, user2

Teraz, jeśli użytkownik 1 lub użytkownik 2 zaloguje się, będą mieli wszystkie uprawnienia do „mydb” bez żadnych dodatkowych przydziałów.

Zastanowiłbym się jednak nad tym rozwiązaniem. Kuszące jest, aby Twoja aplikacja internetowa korzystała z jednego z tych loginów, aby uniknąć bólu związanego z tworzeniem dodatkowych dotacji przy każdej aktualizacji schematu, ale w ten sposób usuwasz bardzo przydatną formę ochrony. Użyj powyższego rozwiązania, jeśli naprawdę chcesz wielu „administratorów”, ale trzymaj się powyższego wzorca „udziel wszystkich uprawnień na wszystkich tabelach w schemacie ...”, aby zalogować się do aplikacji „normalnego użytkowania”.