Jestem trochę zdezorientowany, jeśli chodzi o ustawianie uprawnień w PostgreSQL.
Mam następujące role:
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
admin | Superuser, Create role, Create DB, Replication | {}
meltemi | Create role, Create DB | {rails}
rails | Create DB, Cannot login | {}
myapp | | {rails}
i bazy danych:
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
---------------------+--------+----------+-------------+-------------+-------------------
myapp_production | rails | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
...
użytkownik myapp
nie ma problemu z zapytaniem do myapp_production
bazy danych o dodawanie i usuwanie rekordów. Chciałbym meltemi
również móc wysłać zapytanie do tej samej bazy danych. Stworzyłem rolę, rails
która jest właścicielem bazy danych, i stworzyłem zarówno członków, jak meltemi
i myapp
członków rails
. Ale wciąż dostaję permission denied for relation
błędy. Meltemi
może wyświetlić schemat, ale nie może wykonać zapytania do bazy danych.
Właśnie zauważyłem (z \dt
poleceniem), że myapp
jest właścicielem tabel:
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+-------
public | events | table | myapp
public | schema_migrations | table | myapp
...
public | users | table | myapp
...
Tabele zostały utworzone za pomocą ORM (migracje ActiveRecord w Railsach).
Wiem, że autoryzacja jest bardzo różna w PostgreSQL (w przeciwieństwie do MySQL i innych, z których korzystałem). Jak powinienem skonfigurować bazę danych, aby różni użytkownicy mieli do niej dostęp? Niektóre powinny być w stanie CRUD, ale inne mogą tylko czytać itp.
Dziękuję za wszelką pomoc. Przepraszam, wiem, że to bardzo podstawowe pytanie, ale sam nie znalazłem odpowiedzi.
źródło
myapp
zamiastrails
powyższego? Ponieważmyapp
jest właścicielem tabel (nigdy tego nie określiłem, migracja musi mieć). W każdym razie miałoby to sens, gdybym zmienił nazwęmyapp
na,myapp_group
a następnie stworzyłem nowego użytkownika,myapp
którego aplikacja railsowa użyłaby do połączenia z DB. Markamyapp
i istniejącymeltemi
, obaj członkowiemyapp_group
roli. Ale co się stanie, gdy uruchomię następną migrację. czy nie będzie należał do niegomyapp
ponownie, tworząc problem od nowa?!?roles
(od wersji 8.1). Warunkiuser
igroup
są przechowywane ze względów historycznych i zgodności. Zasadniczo „grupa” to rola bez uprawnień do logowania. Można przyznaćmyapp
sięmeltemi
nawet jeślimyapp
jest to tylko kolejny „user”. Zacznij od przeczytania instrukcji tutaj .roles
vsgroups
vsusers
separacji w PostgreSQL, przynajmniej ja myślę ja. Przepraszam, że użyłem złej (i mylącej) terminologii powyżej. Ale nadal nie rozumiem, jak skonfigurować moją bazę danych, więc rola bez logowania OWNS bazy danych i dwie role logowaniamyapp
imeltemi
oba mogą mieć pełny dostęp. Jedną z tych rólmyapp
będzie uruchamianie migracji Railsów , które nieuchronnie będą tworzyć nowe tabele, które są ponownie własnościąmyapp
użytkownika logowania. Czy powinienem po prostu zostaćmeltemi
członkiemmyapp
i skończyć z tym? Ale to po prostu wydaje się niechlujne ... nie?!?myapp
posiadane przywilejemeltemi
, byłoby to właściwe. Jeśli chceszmeltemi
uzyskać tylko podzbiór uprawnień, nie będzie. Następnie utwórz rolę grupy, aby zachować zestaw uprawnień i nadać jąmeltemi
. Prawdopodobnie będziesz zainteresowany tym powiązanym pytaniem na temat SO . Odpowiedziałem wyjaśniającDEFAULT PRIVILEGES
SET ROLE
polecenie na początku migracji iRESET ROLE
na końcu, ale nie ufam Railsom, aby wszystko działało poprawnie. Erwin ma rację; w takim przypadku najlepszym obejściem będzie,GRANT
że szyny użytkownika dają prawo własności drugiemu użytkownikowi, używając pierwszego użytkownika jako grupy drugiego.