PostgreSQL GRANT ve REVOKE ile Yetkilendirme: Şema, Tablo, Sütun ve Varsayılan Yetkiler

Sahiplik ve yetki: temel kural

Bir nesne oluşturulduğunda, onu oluşturan rol nesnenin sahibi olur. Çoğu nesne türünde başlangıç durumu şudur: yalnızca sahip ve süper kullanıcı nesneyle bir şey yapabilir. Başka rollerin kullanabilmesi için yetki verilmesi gerekir. Nesneyi değiştirme (ALTER) ve silme (DROP) hakkı ise sahipliğin kendisine bağlıdır; bu hak GRANT ile verilemez, REVOKE ile alınamaz. Benzer bir etki istiyorsanız nesnenin sahibi olan role üyelik verirsiniz.

Sahipliği değiştirmek için nesne türüne uygun ALTER ... OWNER TO komutu kullanılır, örneğin ALTER TABLE urunler OWNER TO magaza_sahibi. Süper kullanıcı bunu her zaman yapabilir. Sıradan bir rolün yapabilmesi için hem mevcut sahip olması (ya da sahibin yetkilerini kalıtımla alması) hem de yeni sahip role SET ROLE yapabilmesi gerekir. Sahiplikle birlikte eski sahibin nesne üzerindeki bütün yetkileri de yeni sahibe geçer.

Önemli bir uyarı: süper kullanıcılar nesne yetkilerinden bağımsız olarak her şeye erişir. Belgeler bunu Unix'teki root kullanıcısına benzetir ve kesinlikle gerekmedikçe süper kullanıcıyla çalışılmamasını önerir. Bu yazıdaki yetki kontrollerinin anlamlı olması için uygulamanızın süper kullanıcı olmayan bir rolle bağlanması gerekir.

Yetki türleri ve kısaltmaları

PostgreSQL 18 belgelerinde on beş yetki türü listelenir. Hangisinin anlamlı olduğu nesne türüne göre değişir. psql çıktılarında ve sistem kataloglarında her yetki tek harfle gösterilir:

ALL ya da ALL PRIVILEGES yazdığınızda nesne türü için geçerli bütün yetkiler verilir; tablolar için bu arwdDxtm harflerine karşılık gelir. REFERENCES ve TRIGGER yetkilerinde belgeler ayrıca dikkat ister: foreign key oluşturan bir kullanıcı, kontrol sırasında tablo sahibinin yetkileriyle çalışacak bir fonksiyonu devreye sokabilir; trigger ise tabloyu değiştiren kullanıcının yetkileriyle çalışır.

Bazı nesne türlerinde PUBLIC (bütün roller, ileride oluşturulacaklar dahil) varsayılan olarak yetki alır. Belgelere göre veritabanlarında CONNECT ve TEMPORARY, fonksiyon ve prosedürlerde EXECUTE, dil ve veri tiplerinde USAGE herkese açıktır. Tablolar, sütunlar, sequence'lar ve şemalar ise varsayılan olarak PUBLIC'e hiçbir yetki vermez.

Adım adım: şema, tablo ve eksik yetki hataları

Örnek olarak magaza adlı bir şema kuruyoruz. Şemanın ve tabloların sahibi, oturum açamayan magaza_sahibi rolü olacak. Sahipliği bir NOLOGIN rolde tutmak, nesnelerin tek bir kişiye bağlı kalmasını önler ve o kişi ayrıldığında rolü silmeyi kolaylaştırır.

CREATE ROLE magaza_sahibi;
CREATE ROLE okur LOGIN;
CREATE ROLE yazar LOGIN;
CREATE ROLE stajyer LOGIN;
CREATE SCHEMA magaza AUTHORIZATION magaza_sahibi;
SET ROLE magaza_sahibi;
CREATE TABLE magaza.urunler (id int GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
                             ad text, fiyat numeric(10,2), maliyet numeric(10,2));
INSERT INTO magaza.urunler (ad, fiyat, maliyet)
VALUES ('Türk kahvesi 250 g', 189.90, 120.00), ('Antep fıstığı 500 g', 649.00, 480.00);
CREATE TABLE magaza.siparisler (no serial PRIMARY KEY, urun_id int, adet int);
RESET ROLE;

okur rolü hiçbir yetki almadan bağlanıp ürünleri okumaya çalıştığında ilk engel şemadır. Şemada USAGE verdikten sonra ise sıra tabloya gelir:

-- psql -U okur -d ornek_yetki
SELECT ad FROM magaza.urunler;
-- postgres olarak: GRANT USAGE ON SCHEMA magaza TO okur;
-- tekrar okur olarak:
SELECT ad FROM magaza.urunler;

ERROR:  permission denied for schema magaza
LINE 1: SELECT ad FROM magaza.urunler;
                       ^
ERROR:  permission denied for table urunler

İki hata mesajını ayırt etmek sorun gidermede çok işe yarar. permission denied for schema görüyorsanız eksik olan şema düzeyindeki USAGE'dır; permission denied for table görüyorsanız şemaya girilmiş ama tablo yetkisi yoktur. Belgeler USAGE yetkisinin bir şemadaki nesneleri arayıp bulma hakkı olduğunu, kaldırılsa bile nesne adlarının sistem kataloglarından görülebileceğini ve açık oturumların daha önce yaptığı aramaları kullanmaya devam edebileceğini belirtir; yani bu, erişimi tamamen kesmenin güvenli yolu değildir. Asıl koruma tablo yetkisidir.

ALL TABLES IN SCHEMA ve ALTER DEFAULT PRIVILEGES

Bir şemadaki bütün tablolara tek komutla yetki vermek için ALL TABLES IN SCHEMA kullanılır. Bu yazım tablolar, sequence'lar, fonksiyonlar ve prosedürler için vardır; ALL TABLES görünümleri ve foreign table'ları da kapsar. Fakat komut yalnızca o anda var olan nesneleri etkiler:

GRANT SELECT ON ALL TABLES IN SCHEMA magaza TO okur;
SET ROLE magaza_sahibi;
CREATE TABLE magaza.kampanyalar (kod text, indirim int);
RESET ROLE;
-- okur olarak:
SELECT ad, fiyat FROM magaza.urunler ORDER BY id;
SELECT * FROM magaza.kampanyalar;

         ad          | fiyat  
---------------------+--------
 Türk kahvesi 250 g  | 189.90
 Antep fıstığı 500 g | 649.00
(2 rows)

ERROR:  permission denied for table kampanyalar

Sonradan eklenen kampanyalar tablosu yetkiyi almadı. Bunu çözmek için ALTER DEFAULT PRIVILEGES ile ileride oluşturulacak nesnelerin yetkilerini önceden tanımlarsınız. Burada kritik nokta FOR ROLE kısmıdır: varsayılan yetkiler, nesneyi oluşturan rolün varsayılanlarına göre uygulanır ve üyelik yoluyla miras alınmaz. Tabloları magaza_sahibi oluşturacağı için kuralı onun adına yazıyoruz:

ALTER DEFAULT PRIVILEGES FOR ROLE magaza_sahibi IN SCHEMA magaza GRANT SELECT ON TABLES TO okur;
\ddp
SET ROLE magaza_sahibi;
CREATE TABLE magaza.iadeler (no int, neden text);
RESET ROLE;
\dp magaza.iadeler

               Default access privileges
     Owner     | Schema | Type  |  Access privileges   
---------------+--------+-------+----------------------
 magaza_sahibi | magaza | table | okur=r/magaza_sahibi
(1 row)

                                       Access privileges
 Schema |  Name   | Type  |          Access privileges           | Column privileges | Policies 
--------+---------+-------+--------------------------------------+-------------------+----------
 magaza | iadeler | table | magaza_sahibi=arwdDxtm/magaza_sahibi+|                   | 
        |         |       | okur=r/magaza_sahibi                 |                   | 
(1 row)

Yeni tablo, oluşturulduğu anda okur=r kaydıyla geldi ve okur hiçbir ek komut olmadan SELECT count(*) FROM magaza.iadeler çalıştırabildi. Varsayılan yetkiler şemalar, tablolar (görünümler dahil), sequence'lar, fonksiyonlar, tipler ve büyük nesneler (large object) için ayarlanabilir; büyük nesne desteği PostgreSQL 18 ile eklendi. Şema bazında verilen varsayılanlar genel varsayılanların üzerine eklenir; bu yüzden genel olarak verilmiş bir yetkiyi tek bir şema için geri alamazsınız. Örneğin fonksiyonlardaki PUBLIC EXECUTE yetkisini kaldırmak için IN SCHEMA olmadan ALTER DEFAULT PRIVILEGES FOR ROLE ... REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC yazmanız gerekir.

ACL çıktısını okumak: \dp ve aclitem

\dp komutundaki her satır alan=yetkiler/veren biçimindedir. magaza_sahibi=arwdDxtm/magaza_sahibi, sahibin bütün tablo yetkilerine sahip olduğunu; okur=r/magaza_sahibi ise okur rolünün SELECT (r) aldığını ve yetkiyi verenin magaza_sahibi olarak kaydedildiğini gösterir. Bir harfin arkasında * varsa o yetki WITH GRANT OPTION ile verilmiştir. Eşittir işaretinin solu boşsa yetki PUBLIC'e aittir.

Komutları süper kullanıcı olarak çalıştırdığımız halde veren olarak magaza_sahibi göründü. Belgeler bunu açıklar: süper kullanıcının çalıştırdığı GRANT, nesnenin sahibi çalıştırmış gibi kaydedilir. Access privileges sütunu tamamen boşsa nesne hâlâ yerleşik varsayılan yetkilerdedir; ilk GRANT ya da REVOKE bu varsayılanları açık bir listeye dönüştürür. Aynı listeyi SQL ile almak için PostgreSQL 18 ile gelen pg_get_acl() fonksiyonunu kullanabilirsiniz:

SELECT pg_get_acl('pg_class'::regclass, 'magaza.iadeler'::regclass, 0);

                         pg_get_acl                          
-------------------------------------------------------------
 {magaza_sahibi=arwdDxtm/magaza_sahibi,okur=r/magaza_sahibi}
(1 row)

Sütun düzeyinde yetki

SELECT, INSERT, UPDATE ve REFERENCES belirli sütunlara verilebilir. Stajyerin ürün adını ve fiyatını görmesini, maliyeti ise görmemesini istiyoruz. (Sorguyu, aşağıdaki sequence bölümünde yazar rolü Lokum satırını ekledikten sonra çalıştırdık; üç satır gelmesinin nedeni budur.)

GRANT USAGE ON SCHEMA magaza TO stajyer;
GRANT SELECT (ad, fiyat) ON magaza.urunler TO stajyer;
-- psql -U stajyer -d ornek_yetki
SELECT ad, fiyat FROM magaza.urunler ORDER BY fiyat;
SELECT ad, fiyat FROM magaza.urunler ORDER BY id;
SELECT * FROM magaza.urunler;

         ad          | fiyat  
---------------------+--------
 Türk kahvesi 250 g  | 189.90
 Lokum 1 kg          | 320.00
 Antep fıstığı 500 g | 649.00
(3 rows)

ERROR:  permission denied for table urunler
ERROR:  permission denied for table urunler

İkinci sorgu sürpriz olabilir: seçim listesinde yalnızca izinli sütunlar olmasına rağmen ORDER BY id yetkisiz bir sütuna başvurduğu için reddedildi. Sütun yetkisi, sorgunun herhangi bir yerinde (WHERE, ORDER BY, JOIN koşulu) geçen her sütun için kontrol edilir. SELECT * de bütün sütunları istediği için başarısız olur.

Ters yönde sık yapılan bir hata vardır: tabloya SELECT verip ardından tek bir sütundan REVOKE etmek beklenen sonucu vermez. Belgeler, tablo düzeyindeki yetkinin sütun düzeyindeki bir işlemden etkilenmediğini açıkça belirtir. Bir sütunu gizlemek istiyorsanız tablo düzeyinde yetki vermeyin; yalnızca izin vermek istediğiniz sütunları sayın ya da istenen sütunları gösteren bir görünüm (view) oluşturup yetkiyi ona verin.

Sequence yetkileri: serial ve identity farkı

Belgelere göre bir tabloya yetki vermek, tablonun kullandığı sequence'lara (serial sütunlarına bağlı olanlar dahil) yetki vermez. Bunu iki tabloyla denedik. urunler tablosunun anahtarı GENERATED ALWAYS AS IDENTITY, siparisler tablosununki ise serial:

GRANT USAGE ON SCHEMA magaza TO yazar;
GRANT SELECT, INSERT ON magaza.siparisler, magaza.urunler TO yazar;
-- psql -U yazar -d ornek_yetki
INSERT INTO magaza.urunler (ad, fiyat, maliyet) VALUES ('Lokum 1 kg', 320.00, 210.00);
INSERT INTO magaza.siparisler (urun_id, adet) VALUES (1, 2);

INSERT 0 1
ERROR:  permission denied for sequence siparisler_no_seq

Bizim testimizde identity sütunlu tabloya ekleme, sequence'a ayrıca yetki vermeden çalıştı; serial sütunlu tablo ise nextval çağrısında durdu. Çözüm, sequence'a USAGE (ya da nextval için UPDATE) vermektir:

GRANT USAGE ON SEQUENCE magaza.siparisler_no_seq TO yazar;
-- yazar olarak:
INSERT INTO magaza.siparisler (urun_id, adet) VALUES (1, 2) RETURNING no;   -- sonuç: 1

Çok sayıda tablo varsa GRANT USAGE ON ALL SEQUENCES IN SCHEMA magaza TO yazar ve ileride oluşacaklar için ALTER DEFAULT PRIVILEGES ... GRANT USAGE ON SEQUENCES kullanabilirsiniz. Identity ile serial arasındaki diğer farklar identity, serial ve sequence yazısında anlatılıyor.

Veritabanı düzeyinde CONNECT ve public şeması

Varsayılan olarak her rol her veritabanına bağlanabilir, çünkü CONNECT yetkisi PUBLIC'e verilmiştir. Bir veritabanını yalnızca belirli rollere açmak için önce PUBLIC'ten geri alıp sonra seçtiğiniz rollere verirsiniz:

REVOKE CONNECT ON DATABASE ornek_yetki FROM PUBLIC;
GRANT CONNECT ON DATABASE ornek_yetki TO okur, yazar;

psql -h 127.0.0.1 -p 46460 -U stajyer -d ornek_yetki
# psql: error: connection to server at "127.0.0.1", port 46460 failed: FATAL:  permission denied for database "ornek_yetki"
# DETAIL:  User does not have CONNECT privilege.

CONNECT bağlantı başlarken kontrol edilir ve pg_hba.conf kurallarına ek olarak uygulanır. Yani bir kullanıcının bağlanabilmesi için hem pg_hba.conf satırının hem de bu yetkinin uygun olması gerekir. \l ornek_yetki çıktısında yetki satırları =T/postgres, okur=c/postgres ve yazar=c/postgres olarak göründü: PUBLIC artık yalnızca geçici tablo (T) oluşturabiliyor.

public şeması için de bilinmesi gereken bir değişiklik var. Belgelere göre PostgreSQL 15 ve sonrasının varsayılan yapılandırmasında PUBLIC, public şemasında CREATE hakkına sahip değildir ve şemanın sahibi pg_database_owner rolüdür. Bizim kümemizde \dn+ public tam olarak pg_database_owner=UC/pg_database_owner ve =U/pg_database_owner gösterdi; yani herkes şemayı kullanabiliyor ama içinde nesne oluşturamıyor. PostgreSQL 14 ve öncesinden yükseltilmiş veritabanlarında ise herkesin CREATE yetkisi durabilir; belgeler bu durumda REVOKE CREATE ON SCHEMA public FROM PUBLIC önerir. Şema yapısının ayrıntısı veritabanı ve şema yazısında.

WITH GRANT OPTION ve REVOKE CASCADE

WITH GRANT OPTION ile verilen yetkiyi alan rol, aynı yetkiyi başkalarına da verebilir. Bu seçenek PUBLIC'e verilemez. Yetkiyi geri aldığınızda, bu yetkiye dayanarak başkalarına verilmiş bağımlı yetkiler de vardır ve PostgreSQL bunları varsayılan davranış olan RESTRICT ile sessizce silmez:

GRANT SELECT ON magaza.kampanyalar TO okur WITH GRANT OPTION;
-- okur olarak:
GRANT SELECT ON magaza.kampanyalar TO yazar;
-- postgres olarak:
REVOKE SELECT ON magaza.kampanyalar FROM okur;
REVOKE SELECT ON magaza.kampanyalar FROM okur CASCADE;

ERROR:  dependent privileges exist
HINT:  Use CASCADE to revoke them too.
REVOKE

CASCADE ile çalıştırıldığında hem okur hem de onun yetki verdiği yazar erişimini kaybetti; ardından \dp magaza.kampanyalar yalnızca sahibin satırını gösterdi. Bir rol yalnızca kendisinin verdiği yetkileri geri alabilir: A, B'ye, B de C'ye yetki verdiyse A doğrudan C'den alamaz, B'nin grant option'ını CASCADE ile geri almalıdır. Yalnızca başkalarına verme hakkını kaldırmak için REVOKE GRANT OPTION FOR SELECT ON ... FROM okur yazımı vardır.

Uygulama: salt okunur bir raporlama kullanıcısı

Yukarıdaki parçaları birleştirince, bir şemadaki mevcut ve gelecekteki bütün tabloları okuyabilen ama hiçbir şey değiştiremeyen bir kullanıcı için tarif şöyle olur. Rapor kullanıcısını doğrudan değil bir grup rolü üzerinden yetkilendirmek, ileride ikinci bir rapor kullanıcısı eklemeyi tek satıra indirir:

CREATE ROLE rapor_okuma;                         -- grup, NOLOGIN
GRANT CONNECT ON DATABASE ornek_yetki TO rapor_okuma;
GRANT USAGE ON SCHEMA magaza TO rapor_okuma;
GRANT SELECT ON ALL TABLES IN SCHEMA magaza TO rapor_okuma;
ALTER DEFAULT PRIVILEGES FOR ROLE magaza_sahibi IN SCHEMA magaza
    GRANT SELECT ON TABLES TO rapor_okuma;
CREATE ROLE rapor_kullanici LOGIN IN ROLE rapor_okuma;
-- parolayı etkileşimli psql'de \password rapor_kullanici ile verin

-- psql -U rapor_kullanici -d ornek_yetki
SELECT count(*) FROM magaza.urunler;      -- sonuç: 3
SELECT count(*) FROM magaza.yeni_tablo;   -- sonuç: 0 (kuraldan sonra magaza_sahibi oluşturdu)
DELETE FROM magaza.urunler;               -- ERROR:  permission denied for table urunler

Tarifteki her satırın bir görevi var: CONNECT veritabanına girişi, USAGE şemada nesne bulmayı, ALL TABLES bugünkü tabloları, ALTER DEFAULT PRIVILEGES yarın oluşturulacakları kapsar. IN ROLE, yeni kullanıcıyı gruba INHERIT ile üye yaptığı için ayrıca GRANT gerekmez. Bütün veritabanını okuyacak bir kullanıcıya ihtiyacınız varsa daha kısa yol pg_read_all_data rolüdür; rol yönetimi yazısında örneğini bulabilirsiniz. Yetkileri SQL ile denetlemek için has_table_privilege(), has_column_privilege() ve has_schema_privilege() fonksiyonları vardır; örneğimizde stajyer için tablo düzeyinde f, fiyat sütunu için t döndüler.

Sık yapılan hatalar

• Şema USAGE'ını unutmak: tablo yetkisi verdiğiniz halde permission denied for schema alıyorsanız eksik olan şemadır.
• ALL TABLES IN SCHEMA'nın gelecekteki tabloları kapsadığını sanmak: yalnızca mevcut tabloları etkiler; gelecek için ALTER DEFAULT PRIVILEGES gerekir.
• ALTER DEFAULT PRIVILEGES'ı yanlış rol için yazmak: FOR ROLE verilmezse kural komutu çalıştıran role uygulanır. Tabloları başka bir rol (ör. migration kullanıcısı) oluşturuyorsa kural etkisiz kalır.
• Serial sequence yetkisini atlamak: permission denied for sequence ..._seq hatası, tabloya INSERT verip sequence'a USAGE vermediğinizi gösterir.
• Tablo yetkisini sütun REVOKE ile daraltmaya çalışmak: etkisi olmaz; sütun yetkisini baştan sütun bazında verin.
• Uygulamayı nesnelerin sahibi rolle çalıştırmak: sahip DROP ve ALTER yapabilir. Uygulama kullanıcısını sahipten ayırın.

Sık Sorulan Sorular

Bir kullanıcının hangi tablolara yetkisi olduğunu nasıl görürüm?

psql'de \dp şema.* tablo ve sütun yetkilerini, \ddp varsayılan yetkileri, \l veritabanı yetkilerini, \dn+ şema yetkilerini gösterir. SQL tarafında has_table_privilege('rol', 'tablo', 'SELECT') gibi fonksiyonlarla tek tek sorgu yapabilirsiniz.

GRANT verdim ama kullanıcı hâlâ erişemiyor, neden?

En sık nedenler şunlardır: şemada USAGE yok, sorgu yetkisiz bir sütuna başvuruyor, serial sequence'a yetki yok ya da tablo GRANT komutundan sonra silinip yeniden oluşturulmuş. RLS etkinse yetki olsa bile politika satırları gizleyebilir; RLS yazısına bakın. Hata kodlarının listesi SQLSTATE yazısında var.

Fonksiyonlar neden herkes tarafından çağrılabiliyor?

Fonksiyon ve prosedürlerde EXECUTE yetkisi varsayılan olarak PUBLIC'e verilir. Kısıtlamak için REVOKE EXECUTE ON FUNCTION ad(argtipleri) FROM PUBLIC çalıştırın; belgeler, arada boşluk kalmaması için bunun nesneyi oluşturan transaction içinde yapılmasını önerir. Fonksiyon tanımı için CREATE FUNCTION yazısına bakabilirsiniz.

GRANT ve REVOKE PostgreSQL 18'de değişti mi?

Sürüm notlarına göre PostgreSQL 18, 8.2'den beri çalışmayan kural (rule) yetkisi desteğini GRANT ve REVOKE'tan kaldırdı; pg_get_acl() ve has_largeobject_privilege() fonksiyonlarını ekledi ve ALTER DEFAULT PRIVILEGES komutuna büyük nesne desteği getirdi. Bütün yenilikler PostgreSQL 18 yenilikleri yazısında.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: PostgreSQL öğrenme rehberi · Kullanıcı ve rol yönetimi · Row level security · View ve materialized view · Identity, serial ve sequence · pg_hba.conf ve uzak bağlantı · SQL injection önleme