GRANT  <yetki>[(<kolon> [, …])] [, …] [ON <nesne> [, …]] TO   <alıcı> [, …]
  [WITH ADMIN OPTION | WITH GRANT OPTION]
REVOKE [GRANT OPTION FOR | ADMIN OPTION FOR] <yetki>[(<kolon> [, …])] [, …] [ON <nesne> [, …]] FROM <alıcı> [, …]
  [CASCADE | RESTRICT]

Gövde ikisinde aynıdır; alıcı TO yerine FROM'dan sonra gelir. Alıcı listesi zorunludur (yoksa sözdizimi hatası). … OPTION FOR ile CASCADE/RESTRICT yalnızca REVOKE'ta geçerlidir — bkz. “Zincirli iptal”.

Devir ölçütü bağlama göredir ve karıştırılamaz: bir nesne hakkı GRANT OPTION, bir rol üyeliği ADMIN OPTION alır. Yanlış sözcüğü yazmak sözdizimi hatasıdır — standardın ve PostgreSQL'in ayrımı budur, ve sessizce kabul edilseydi GRANT <rol> TO <u> WITH GRANT OPTION yazan biri devir verdiğini sanıp vermemiş olurdu.

İkisi de aynı yerde saklanır (ivd$grant_option), yani denetim, önbellek ve zincirli iptal makinesinin tamamı ikisi için de aynı biçimde çalışır. GRANT/REVOKE yazabilmek için bu ölçüte sahip olmak gerekir; nesnenin ya da rolün sahibi ve yönetici muafiyetleri bundan bağımsızdır.

Verilen haklar SYS.IVD$OBJECT_PRIVILEGES tablosunda saklanır ve uygulanır. Denetim koşma anında yapılır, derleme anında değil: derlenmiş deyim önbelleğe alındığı için derlemede sorulan bir hak, sonradan verilen bir GRANT'i görmezden gelirdi. Yetersiz hak deyimi no SELECT privilege on … biçiminde bir hatayla düşürür (SQLSTATE 42501).

Bir satır (nesne, alıcı, veren) üçlüsüdür ve haklar tek bir bit kümesidir: GRANT kümeye ekler, REVOKE çıkarır, küme boşalınca satır silinir. Olmayan bir hakkı geri almak satır açmaz. Alıcı bir kullanıcı, bir rol ya da PUBLIC olabilir; rol üyelikleri geçişli çözülür (rol içinde rol).

Veren de anahtarın parçasıdır: aynı hakkı aynı alıcıya iki ayrı kullanıcı verdiyse iki ayrı satır oluşur ve alıcının etkin hakkı hepsinin birleşimidir. Bunun iki görünür sonucu vardır. Birincisi, REVOKE yalnızca çağıranın kendi bağışına dokunur: başkasının verdiği aynı hak yerinde kalır. İkincisi, bu kayıt olmadan zincirli iptal kurulamaz — kimin kime verdiği bilinmeden hangi bağışın dayanağının kalktığı da bilinemez. Verenin boş (NULL) olduğu satırlar motorun bağışlarıdır (önyükleme, CREATE DATABASE'in sahip satırı, kimliksiz bağlantı) ve geri alınamazlar.

6.5.1 Kolon düzeyi haklar

“Herhangi bir kolon yeter” kuralı yalnızca okumadadır: adlı bir kolona dokunmayan deyim herhangi bir kolondaki SELECT ile geçer; INSERT/UPDATE/DELETE için tablo düzeyindeki hak şarttır. Çözülemeyen (bilinmeyen) bir hedefte cevap “izin yok”tur.

Kolon hakkı tabloya düşer: bir kullanıcının t.a kolonunda SELECT (ya da GRANT OPTION) taşıyıp taşımadığı sorulduğunda tablo düzeyindeki satır ve tablonun sahipliği de sayılır — çalışma anı denetiminin izlediği sıra. Bu yüzden tablonun sahibinin verdiği kolon hakları zincirli REVOKE'ta “sahipsiz” sayılmaz.

Dört hak kolon listesi alır: SELECT, INSERT, UPDATE ve REFERENCES — standardın dörtlüsü, PostgreSQL ve SQL Server da aynısını alır. DELETE almaz, çünkü silinen şey satırın tamamıdır; kolon kabul etmeyen bir hakka liste yazmak sözdizimi hatasıdır, olmayan bir kolon adı da öyle.

GRANT SELECT(ad, soyad), UPDATE(telefon) ON musteri TO temsilci;
REVOKE SELECT(soyad) ON musteri FROM temsilci CASCADE;

Ayrı bir yapı yoktur: bu motorda bir kolon birinci sınıf katalog nesnesidir (kendi nesne kimliğiyle, ivd$type = 'FIELD', sahibi tablo), dolayısıyla kolon hakkı nesnesi kolon olan sıradan bir hak satırıdır. Zincirli iptal, DROP temizliği ve önbellek onun için de olduğu gibi çalışır. Bunun görünür sonucu: “bu tabloda ne verilmiş” sorusu tablonun kolonlarına da bakmak zorundadır.

Denetimin sırası önce tablo, sonra kolondur. Tablo düzeyinde hak varsa soru biter ve bütün muafiyetler (sahip, SYSDBA, SYSADMIN, READ_ALL_DATA) olağan biçimde işler. Yalnızca orada hak yoksa kolon düzeyine inilir ve deyimin dokunduğu her kolon ayrı ayrı aranır; bir kolon bile eksikse deyim düşer. Hangi kolonlara dokunulduğu deyimin türüne bağlıdır:

Bir deyim tablonun hiçbir kolonuna dokunmuyorsa (SELECT count(*) FROM t) tablonun herhangi bir kolonundaki hak yeter — PostgreSQL'in davranışı. Gerekçesi: bir kolonu okuyabilen satır sayısını zaten öğrenebilir, ama hiçbir hakkı olmayana satır sayısı sızdırılmamalı.

6.5.2 Yazılan kolon ile okunan kolon ayrı haklardır

Bir deyimin yazdığı kolon yazma hakkını, okuduğu kolon ise ayrıca SELECT hakkını ister. Standardın (SQL:2016, 14.14) ve PostgreSQL, SQL Server ile MySQL'in kuralı budur. Okunan kolon yalnızca WHERE'de değil, SET'in değer tarafında ve birleştirme koşullarında da olabilir:

GRANT SELECT(a), UPDATE(a), UPDATE(c) ON t TO u;

UPDATE t SET c = 9;              -- hiçbir kolon okunmuyor: SELECT gerekmez
UPDATE t SET a = a + 1;          -- a okunuyor: SELECT(a) de gerekir (var)
UPDATE t SET a = b;              -- b okunuyor: SELECT(b) yok, deyim düşer
UPDATE t SET c = 9 WHERE b = 2;  -- aynı şekilde düşer
DELETE FROM t WHERE b = 2;       -- silmek için DELETE, b'yi okumak için SELECT(b)

6.5.3 RETURNING bir okumadır

RETURNING ile geri dönen her kolon okunmuş sayılır ve SELECT ister — PostgreSQL de böyle davranır ve yazılan kolona muafiyet tanımaz. Muafiyet olmamasının somut gerekçesi vardır: dönen değer çağıranın yazdığı değer olmayabilir, araya bir DEFAULT, bir sıra ya da bir tetikleyici girmiş olabilir.

GRANT INSERT ON t TO u;              -- hiçbir kolonda SELECT yok

INSERT INTO t(a, b) VALUES (1, 10);                    -- geçer
INSERT INTO t(a, b) VALUES (2, 20) RETURNING c;        -- SELECT(c) yok: düşer
INSERT INTO t(a, b) VALUES (3, 30) RETURNING b;        -- yazılan kolon da SELECT ister

6.5.4 MERGE ve UPDATE OR INSERT: hak eylem başına

MERGE hedef tabloda, yalnızca yazılmış WHEN dallarının haklarını ister — hepsini değil. PostgreSQL, SQL Server ve Oracle da böyle davranır.

Bunlara ek olarak kaynakta SELECT, hedefte ise ON koşulunun, WHEN koşullarının ve değer ifadelerinin okuduğu kolonlarda SELECT gerekir. Yani INSERT ve UPDATE hakkı olan bir kullanıcının MERGE'ü çalışır, ama aynı deyime bir WHEN MATCHED THEN DELETE dalı eklenirse yalnızca o dal yüzünden reddedilir.

UPDATE OR INSERT adının söylediği gibi iki iş yapar: var olan satırı güncelleyebildiği için INSERT'ün yanı sıra UPDATE hakkı da ister.

6.5.5 Haklar

6.5.6 DDL de denetlenir: kap kuralı

Sistem nesneleri: okumak ve kullanmak (SELECT, EXECUTE, USAGE) herkese açıktır, aralarındaki uygulama tablolarına (IVD$EVENT_LOG gibi) yazmak serbesttir; ama yapı değişikliği — ALTER, DROP, sistem şemasının içine CREATE, TRIGGER, REFERENCES — yalnızca kimliksiz bağlantıya, önyükleme login'i SYSDBA'ya ve motorun kendi SYSTEM kapsamına açıktır. Sıradan bir login'in ALTER USER SYSDBA …, ALTER SEQUENCE SYS.IVD$OBJECT_ID … ya da DROP TABLE SYS.IVD$… yazması 42501 verir; SYSADMIN muaf değildir (rol üyesi önyükleme login'ini ele geçirebilirdi).

Bir nesneyi yaratmak, onu tutacak kabın hakkını ister; değiştirmek ve düşürmek nesnenin kendisinde ALTER / DROP ister.

GRANT/REVOKE'un kendisi de denetlenir: bir hakkı başkasına vermek için o hakkın verende WITH GRANT OPTION ile bulunması (ya da verenin nesnenin sahibi olması) gerekir. Standardın kuralı budur. Rol vermek de aynı denetimden geçer, ölçütü rolün üzerindeki ADMIN OPTION'dır — yerleşik roller dahil: SYSADMIN bir sistem nesnesidir ama rol üyeliği o muafiyetin dışında tutulur, yoksa herkes kendini yönetici yapabilirdi.

6.5.7 SQL SECURITY: gövde kimin haklarıyla koşar

Bir yordam, işlev (toplam işlevler dâhil) ya da tetikleyici gövdesi öndeğerde çağıranın haklarıyla koşar (INVOKER) — PostgreSQL'in de öndeğeri budur. SQL SECURITY DEFINER yazılırsa gövde nesnenin sahibinin haklarıyla koşar:

CREATE PROCEDURE gizli_oku RETURNS (v INTEGER)
SQL SECURITY DEFINER
AS
BEGIN
  SELECT a FROM gizli INTO :v;
  SUSPEND;
END;

GRANT EXECUTE ON PROCEDURE gizli_oku TO temsilci;   -- `gizli` tablosunda hak GEREKMEZ

Bu, GRANT EXECUTE'u gerçek bir kapsülleme aracı yapar: yordamı çağırabilen, yordamın dokunduğu tablolarda ayrıca hak sahibi olmak zorunda değildir. Aynı şey tetikleyicide denetim günlüğü yazmayı mümkün kılar: bir tabloya INSERT verilen kişiye, tetikleyicinin yazdığı günlük tablosunda ayrıca hak verilmesi gerekmez.

6.5.8 DENY yoktur

Bu motorda açık bir red yoktur. Model “vermediğin hak zaten yoktur” modelidir: DENY yalnızca SQL Server'da bulunur; standart böyle bir yapı tanımlamaz, PostgreSQL, Oracle, MySQL, Firebird ve DB2 de tanımaz.

Gerekçesi maliyetidir: bir reddin tek varlık sebebi, başka bir yerden — bir rolden ya da PUBLIC'ten — gelen bağışı yenmesidir. Bu da etkin hakkı “bağışların birleşimi” olmaktan çıkarıp (bağışların birleşimi) ve (redlerin birleşimi) değil hâline getirir ve üç şeyi yeniden tanımlar:

• PUBLIC'in anlamı: “herkesin taban bağışı”nın yanında “herkesin taban reddi” olurdu ve açıkça GRANT almış bir kullanıcıyı da keserdi.
• Muafiyet merdiveni: SYSADMIN, SYSDBA ve sahibin reddi aşıp aşmayacağı ayrıca yazılmak zorunda kalırdı.
• REVOKE: tek sözcük iki ayrı şeyi (bağışı ve reddi) kaldırırdı.

DENY bir anahtar sözcük bile değildir, dolayısıyla yazılması sessizce yok sayılmaz: SYNTAX_ERROR verir. Aynı ihtiyacın karşılanma yolu öteki motorlardakiyle aynıdır: hakkı role değil kişiye vermek, ya da kişiyi rolden çıkarmak.

6.5.9 Zincirli iptal

Devredilebilir bir hak geri alındığında, o hakka dayanan bağışlar dayanaksız kalır: A, B'ye WITH GRANT OPTION ile SELECT vermiş, B de C'ye SELECT vermişse, A'nın geri alması B'nin verme yetkisini de düşürür ve C'nin hakkının arkasında kimse kalmaz.

Ölçüt tek bir sorudur ve nesne üzerindeki her bağışa sorulur: bu satırın vereni bu hakkı hâlâ devredebiliyor mu? Edemiyorsa satır dayanaksızdır. Soru böyle kurulmuştur, çünkü bir alıcı aynı hakkı PUBLIC satırından ya da bir rol üzerinden de taşıyor olabilir — “kim kimden aldı” tek bir bağla temsil edilmez.

REVOKE GRANT OPTION FOR <yetki> … — rol üyeliğinde REVOKE ADMIN OPTION FOR <rol> … — hakkın kendisini alıcıda bırakır, yalnızca devretme yetkisini düşürür; standartta CASCADE'in asıl kullanım yeri budur. Rol üyelikleri de zincirin içindedir: devri kalkan bir üyelikle verilmiş alt üyelikler dayanaksız kalır. Bir kullanıcı ya da rol düşürüldüğünde onun verdiği bağışlar da gider; veren yok olduktan sonra o bağışı geri alabilecek kimse kalmazdı.

6.5.10 Kimler muaf

6.5.11 Yerleşik kullanıcılar ve roller

Hepsi her veritabanında, sabit nesne kimliğiyle bulunur; adları yeniden kullanılamaz (CREATE USER SYSDBA → duplicate USER name).

6.5.12 Katalog okunur, ama yazılamaz

Sistem nesneleri (IVD$* katalog tabloları, yerleşik paketler, yerleşik alan tipleri) herkese okunur: SELECT, EXECUTE ve USAGE sorulmaz. Bu yerleşik bir kalıptır — PostgreSQL'de pg_catalog ve information_schema, Firebird'de RDB$* da PUBLIC'e okunurdur. Aynı kural depoda da geçerlidir: PostgreSQL ve Firebird veritabanında ivd$* tablolarında PUBLIC'in yalnız SELECT hakkı vardır (PostgreSQL'de katalog şemasının USAGE hakkı da), yani IVEDI dışından bağlanan her kullanıcı kataloğu okuyabilir, yazamaz. Hak katalog kurulurken verilir; eksikse ALTER DATABASE <db> UPGRADE ve UPGRADE LEVEL tamamlar.

Buna karşılık katalog tablolarına doğrudan yazmak tümüyle kapalıdır: SYSDBA ve SYSADMIN dâhil hiç kimse IVD$OBJECTS, IVD$USER_MAP, IVD$OBJECT_PRIVILEGES gibi tablolara INSERT/UPDATE/DELETE yapamaz; yazan tek şey motorun kendi bakım yollarıdır ve onlar bunu dahili kimlik adına yapar. PostgreSQL'de de superuser allow_system_table_mods açılmadan katalog tablosuna yazamaz.

6.5.13 Görünüm bir yetki aracıdır

Bir görünümden okumak için çağırana görünümde SELECT yeter; gövdesinin tabloları görünümün sahibi adına denetlenir (PostgreSQL'in ve standardın definer modeli). Böylece bir tablonun yalnız bir kısmını gösteren görünüm, o tabloya hiç hakkı olmayan kullanıcıya verilebilir — kullanıcı tabloya doğrudan eriştiğinde yine reddedilir. Türetilmiş tablo ve CTE birer katalog nesnesi değildir; onların gövdesi çağıranın kimliğiyle koşar.

Görünüm üzerinden yazmak da aynı modeldir: güncellenebilir bir görünüme INSERT / UPDATE / DELETE / MERGE için hak görünümde aranır, taban tablo görünümün sahibi adına denetlenir. Kolon düzeyi haklar görünümde de geçerlidir: GRANT SELECT(a), UPDATE(b) ON v TO u yazan, tablodaki merdivenin aynısını alır — görünüm düzeyinde hak yoksa okunan her görünüm kolonunda SELECT, yazılan her görünüm kolonunda yazma hakkı gerekir; hiçbir kolon okumayan count(*) herhangi bir kolondaki hakla geçer; DELETE kolon almaz. INSERT ... RETURNING ile dönen görünüm kolonu da SELECT ister. Görünümün kendi WHERE'inden gelen taban kolonları çağırandan sorulmaz; onlar sahibin hakkıyla denetlenir.

RETURNING listesindeki bir ifadenin içindeki alan da SELECT ister (returning c + 0, coalesce(c, 0), case when c ...); UPDATE OR INSERT ... MATCHING (a) ise a'yı okur, yani a'da SELECT gerekir.

6.5.14 Haklar depolama motoruna da yansır

PostgreSQL ya da Firebird üzerinde saklanan bir tablo/görünüm için verilen ya da alınan hak, katalog satırı yazıldıktan sonra depolama motorunun kendi yetki sistemine de uygulanır: GRANT SELECT, UPDATE (b) ON t TO u IVEDI'de kaydedilir ve PostgreSQL'e GRANT SELECT, UPDATE (b) ON t TO u olarak gider. Böylece aynı adlı motor rolü tabloya IVEDI dışından (psql, isql, başka bir uygulama) eriştiğinde aynı hakları görür. Kurallar:

• IVEDI kullanıcı/rol adı motor rolünün adıdır; ad motorun tanımlayıcı kuralıyla yazılır (tırnaksız u PostgreSQL'de u, Firebird'de U). PUBLIC PUBLIC'tir. Ad eşleşmesi dışında bir haritalama yoktur.
• Yalnızca tablo/görünüm hakları (SELECT/INSERT/UPDATE/DELETE/REFERENCES), tablo ve kolon düzeyi; Firebird kolon listesini yalnızca UPDATE/REFERENCES için bilir, kolon listeli SELECT/INSERT orada atlanır. Yordam, sıra ve veritabanı hakları iletilmez. WITH GRANT OPTION ve REVOKE GRANT OPTION FOR taşınır. PostgreSQL'de her GRANT alıcıya nesnenin şemasında USAGE da verir; REVOKE şemaya dokunmaz.
• Motorun reddi IVEDI deyimini düşürmez: rol yoksa (role "x" does not exist) günlüğe WARNING düşer, IVEDI hak satırı kalır. IVEDI doğruluk kaynağıdır, motor kopyası en iyi gayrettir. Bellek/EMR/sqlite/BlackHole motorlarında kullanıcı kavramı olmadığı için hiçbir şey yapılmaz.

6.5.15 Veritabanları arası

Kimlik iki katmanlıdır: login MASTER'da yaşar, her veritabanı kendi kullanıcı nesnesini taşır ve aynı login her veritabanında farklı adla bulunabilir. Hak denetimi bu yüzden hedefin kendi veritabanındaki kullanıcıyla ve o kataloğun hak tablosundan yapılır; birleştiren şey MASTER.SYS.IVD$USER_MAP'tir. Aynı kural GRANT'in kendisi için de geçerlidir — alıcı, hedefin kataloğundaki kullanıcıdır — ve başka bir veritabanındaki nesneye hak vermek üç parçalı adla yazılır: grant select on xa.xs.t to kullanici;

Yerleşik kullanıcılar haritaya girmez: SYSTEM, SYSDBA ve GUEST her katalogda aynı ad ve aynı kimlikle bulunduğu için eşleşmeleri bir kayıt değil yapısal bir gerçektir. Harita yalnızca sıradan login'ler içindir.

6.5.16 Kullanıcı tanımı

CREATE USER <ad> [<yan tümce> …]
ALTER  USER <ad> <yan tümce> [<yan tümce> …]