PostgreSQL: izin ditolak untuk hubungan


14

Saya agak bingung tentang pengaturan izin di PostgreSQL.

Saya memiliki peran ini:

                             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}

dan basis data:

                                    List of databases
        Name         | Owner  | Encoding |   Collate   |    Ctype    | Access privileges 
---------------------+--------+----------+-------------+-------------+-------------------
 myapp_production    | rails  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 ...

pengguna myapptidak memiliki masalah meminta myapp_productiondatabase menambahkan & menghapus catatan. Saya ingin meltemijuga dapat meminta database yang sama. Jadi, saya membuat peran railsyang memiliki database dan membuat keduanya meltemidan myappanggota rails. Tapi saya masih mendapatkan permission denied for relationkesalahan. Meltemidapat melihat skema tetapi tidak dapat meminta DB.

Saya hanya melihat (dengan \dtperintah) yaitu myapppemilik tabel:

             List of relations
 Schema |       Name        | Type  | Owner 
--------+-------------------+-------+-------
 public | events            | table | myapp
 public | schema_migrations | table | myapp
 ...
 public | users             | table | myapp
 ...

Tabel dibuat melalui ORM (migrasi ActiveRecord Rails ').

Saya tahu otorisasi sangat berbeda di PostgreSQL (berbeda dengan MySQL & yang lain yang pernah saya gunakan). Bagaimana saya mengatur database saya sehingga pengguna yang berbeda dapat mengaksesnya. Beberapa harus dapat CRUD tetapi yang lain hanya dapat membaca, dll ...

Terima kasih atas bantuannya. Maaf, saya tahu ini adalah pertanyaan yang sangat mendasar tetapi saya belum dapat menemukan jawabannya sendiri.

Jawaban:


4

Saya baru saja menulis tentang ini dalam jawaban saya untuk Pemberian hak pada database postgresql kepada pengguna lain di ServerFault.

Pada dasarnya, solusi terbaik ketika Anda memiliki satu pengguna dan Anda ingin memberikan hak yang sama kepada pengguna lain adalah mengubah pengguna itu menjadi grup, membuat pengguna baru dengan nama yang sama dengan yang asli yang menjadi anggota grup, dan berikan grup itu ke pengguna lain juga.

Jadi, dalam kasus Anda, railsdiganti namanya menjadi myapp_users, maka Anda membuat peran masuk baru (pengguna) bernama railsdan GRANT myapp_users TO rails. Sekarang kamu seorang GRANT myapp_users TO meltemi. railsAkun baru dan meltemipengguna sekarang memiliki hak railsakun lama .

Untuk kontrol yang lebih halus saya biasanya menyarankan agar Anda menghindari memberikan pengguna login sehari-hari atau kelompok mereka kepemilikan tabel. Berikan mereka akses melalui NOINHERITgrup yang harus mereka secara eksplisit SET GROUPgunakan, atau lebih baik, gunakan pengguna yang sama sekali berbeda untuk operasi istimewa seperti DDL dan GRANTs. Sayangnya ini tidak berfungsi dengan Rails, karena Rails suka menerapkan migrasi kapan pun ia mau dan AFAIK tidak memberi Anda kemampuan untuk menentukan pengguna lain yang lebih istimewa untuk menjalankan migrasi tersebut.


OK, baca posting yang Anda tautkan; sangat membantu! Sekarang, jika saya memahami hal-hal dengan benar, saya pikir Anda mungkin bermaksud menggunakan myappalih-alih di railsatas? Karena myappmemiliki tabel (saya tidak pernah menentukan itu, migrasi harus ada). Bagaimanapun, akan lebih masuk akal jika saya berganti nama myappmenjadi myapp_groupdan kemudian membuat pengguna baru myappyang aplikasi rel akan gunakan untuk terhubung ke DB. Buat myappdan yang ada meltemi, kedua anggota myapp_groupperan. Tetapi apa yang terjadi ketika saya menjalankan migrasi berikutnya. bukankah itu akan dimiliki dengan myappmenciptakan kembali masalah lagi?!?
Meltemi

1
Anda harus memahami bahwa PostgreSQL hanya memiliki roles(sejak versi 8.1). Persyaratan userdan groupdisimpan untuk alasan historis dan kompatibilitas. Pada dasarnya "grup" adalah peran tanpa hak masuk. Anda dapat memberikan myappke meltemibahkan jika myapphanyalah "pengguna". Mulailah dengan membaca manual di sini .
Erwin Brandstetter

Saya mengerti pemisahan rolesvs groupsvs usersdi Postgres, setidaknya saya pikir saya mengerti . Maaf menggunakan terminologi yang salah (dan membingungkan) di atas. Tapi saya masih tidak mengerti cara mengatur basis data saya sehingga peran tanpa-masuk SENDIRI pada basis data dan dua peran masuk myappdan meltemikeduanya dapat memiliki akses penuh. Salah satu peran itu myappakan menjalankan migrasi Rails yang, mau tidak mau?, Membuat tabel baru yang, sekali lagi, dimiliki oleh myapp, seorang pengguna login. Haruskah saya membuat meltemi'anggota' myappdan selesai dengan itu? Tapi itu sepertinya kludgy ... tidak?!?
Meltemi

1
@Meltemi: Jika Anda ingin memberikan semua hak istimewa yang myappdimiliki meltemi, maka itu akan menjadi hal yang benar untuk dilakukan. Jika Anda ingin meltemimendapatkan hanya sebagian dari hak istimewa, itu tidak akan terjadi. Kemudian buat peran kelompok untuk memegang set hak istimewa dan berikan itu meltemi. Anda kemungkinan besar akan tertarik pada pertanyaan terkait ini di SO . Saya menjawab menjelaskanDEFAULT PRIVILEGES
Erwin Brandstetter

@Meltemi Ya, seperti biasanya migrasi Rails memperumit gambar. Rails seharusnya memungkinkan Anda menentukan akun pengguna yang berbeda untuk menjalankan migrasi. Anda mungkin dapat menambahkan SET ROLEperintah ke awal migrasi dan a RESET ROLEsampai akhir, tapi saya tidak akan percaya Rails untuk menjalankan semuanya dengan rapi secara berurutan. Erwin benar; dalam hal ini solusi terbaik GRANTadalah rel pengguna memberikan kepemilikan kepada pengguna lain, menggunakan pengguna pertama sebagai grup untuk pengguna kedua.
Craig Ringer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.