Berikan semua pada skema tertentu di db ke peran grup di PostgreSQL


93

Dengan menggunakan PostgreSQL 9.0, saya memiliki peran grup yang disebut "staf" dan ingin memberikan semua (atau beberapa) hak istimewa untuk peran ini pada tabel dalam skema tertentu. Tak satu pun dari karya berikut ini

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

Anggota "staf" masih tidak dapat MEMILIH atau MEMPERBARUI tabel individu dalam skema "foo" atau (dalam kasus perintah kedua) ke tabel mana pun dalam database kecuali saya memberikan semua pada tabel tertentu itu.

Apa yang bisa saya lakukan untuk membuat hidup saya dan pengguna saya lebih mudah?

Pembaruan: Menemukannya dengan bantuan pertanyaan serupa di serverfault.com .

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;

Jawaban:


125

Anda menemukan cara singkat untuk menyetel hak untuk semua tabel yang ada dalam skema yang diberikan. Manual menjelaskan :

(tapi perhatikan itu ALL TABLESdianggap termasuk view dan tabel asing ).

Penekanan saya yang berani. serialkolom diimplementasikan dengan nextval()on berurutan sebagai default kolom dan, mengutip manual :

Untuk urutan, hak istimewa ini memungkinkan penggunaan fungsi currvaldan nextval.

Jadi jika ada serialkolom, Anda juga ingin memberikan USAGE(atau ALL PRIVILEGES) pada urutan

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Catatan: kolom identitas di Postgres 10 atau yang lebih baru menggunakan urutan implisit yang tidak memerlukan hak istimewa tambahan. (Pertimbangkan untuk mengupgrade serialkolom.)

Bagaimana dengan objek baru ?

Anda juga akan tertarik DEFAULT PRIVILEGESuntuk pengguna atau skema :

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Ini menetapkan hak istimewa untuk objek yang dibuat di masa mendatang secara otomatis - tetapi tidak untuk objek yang sudah ada sebelumnya.

Hak istimewa default hanya diterapkan ke objek yang dibuat oleh pengguna yang ditargetkan ( FOR ROLE my_creating_role). Jika klausa itu dihilangkan, defaultnya adalah pengguna saat ini yang mengeksekusi ALTER DEFAULT PRIVILEGES. Untuk lebih eksplisit:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Perhatikan juga bahwa semua versi pgAdmin III memiliki bug halus dan menampilkan hak istimewa default di panel SQL, meskipun tidak berlaku untuk peran saat ini. Pastikan untuk menyesuaikan FOR ROLEklausa secara manual saat menyalin skrip SQL.


2
Asal Anda tahu Erwin, 10 menit setelah Anda memposting saran Anda, saya membutuhkannya. Ini seperti Anda tahu apa yang akan saya lakukan ... membuat tabel baru dan menemukan itu tidak memiliki privasi yang tepat. Jawaban Anda datang untuk menyelamatkan.
punkish

5
@punkish: Saya menuntut lencana precog saya! Sial, itu sudah digunakan untuk hal lain.
Erwin Brandstetter

Saat menjalankan, ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;bagaimana cara mengetahui database apa? SCHEMA foobisa ada di database yang berbeda?
J86

2
@ J86: berlaku untuk database saat ini saja - tempat perintah dijalankan.
Erwin Brandstetter

1
@ErwinBrandstetter Can I akses hibah untuk masa tabel / urutan ke app_user (baca-tulis) asalkan tabel akan dibuat oleh berdedikasi lain migration_user otomatis (migrasi jalur terbang dijalankan pada startup aplikasi)?
lexeme

45

Jawaban saya mirip dengan yang ini di ServerFault.com .

Menjadi Konservatif

Jika Anda ingin lebih konservatif daripada memberikan "semua hak istimewa", Anda mungkin ingin mencoba sesuatu yang lebih seperti ini.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

Penggunaan publicthere mengacu pada nama skema default yang dibuat untuk setiap database / katalog baru. Ganti dengan nama Anda sendiri jika Anda membuat skema.

Akses ke Skema

Untuk mengakses skema sama sekali, untuk tindakan apa pun, pengguna harus diberikan hak "penggunaan". Sebelum pengguna dapat memilih, menyisipkan, memperbarui, atau menghapus, pengguna harus terlebih dahulu diberikan "penggunaan" untuk skema.

Anda tidak akan melihat persyaratan ini saat pertama kali menggunakan Postgres. Secara default, setiap database memiliki skema pertama bernama public. Dan setiap pengguna secara default telah secara otomatis diberikan hak "penggunaan" untuk skema tertentu itu. Saat menambahkan skema tambahan, Anda harus memberikan hak penggunaan secara eksplisit.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Kutipan dari dokumen Postgres :

Untuk skema, izinkan akses ke objek yang terdapat dalam skema yang ditentukan (dengan asumsi bahwa persyaratan hak istimewa objek juga terpenuhi). Pada dasarnya, ini memungkinkan penerima untuk "mencari" objek dalam skema. Tanpa izin ini, masih mungkin untuk melihat nama objek, misalnya dengan menanyakan tabel sistem. Selain itu, setelah mencabut izin ini, backend yang ada mungkin memiliki pernyataan yang sebelumnya telah melakukan pencarian ini, jadi ini bukan cara yang sepenuhnya aman untuk mencegah akses objek.

Untuk pembahasan lebih lanjut lihat Pertanyaan, Apa sebenarnya yang dilakukan GRANT USAGE ON SCHEMA? . Beri perhatian khusus pada Answer oleh pakar Postgres Craig Ringer .

Objek yang Ada versus Masa Depan

Perintah ini hanya mempengaruhi objek yang ada. Tabel dan semacamnya yang Anda buat di masa mendatang mendapatkan hak istimewa default sampai Anda menjalankan ulang baris di atas. Lihat jawaban lain oleh Erwin Brandstetter untuk mengubah default sehingga mempengaruhi objek masa depan.


1
selain dua hibah di atas, perlu satu hibah lagi: PENGGUNAAN GRANT PADA SKEMA public TO some_user_;
Ning Liu

1
@NingLiu Terima kasih banyak telah menunjukkan PENGGUNAAN GRANT, dan untuk mengajari saya itu. Saya menambahkan bagian ke Jawaban.
Basil Bourque

GRANT USAGE ON SCHEMA adalah apa yang saya cari.
Basil Musa
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.