PostgreSQL Kullanıcı ve Rol Yönetimi: CREATE ROLE, Üyelik ve Önceden Tanımlı Roller

Rol nedir, kullanıcıdan farkı var mı?

Belgelere göre rol, nasıl ayarlandığına bağlı olarak bir veritabanı kullanıcısı, bir kullanıcı grubu ya da ikisi birden olabilir. PostgreSQL 8.1'den önce kullanıcı ve grup ayrı kavramlardı; bugün yalnızca rol vardır. Bu tasarımın pratik sonucu şudur: bir rol hem nesnelerin (tablo, fonksiyon, şema) sahibi olabilir, hem başka rollere yetki verebilir, hem de başka bir rolün üyesi olabilir.

İki önemli ayrıntıyı baştan bilmekte fayda var. Birincisi, veritabanı rolleri işletim sistemi kullanıcılarından tamamen bağımsızdır. Sunucuda ayse adında bir Linux kullanıcısı olmasa da ayse rolü oluşturabilirsiniz. İkincisi, roller bir veritabanına değil kümeye (cluster) aittir. Aynı sunucudaki bütün veritabanlarında aynı rol listesi görünür; bir veritabanında oluşturduğunuz rol diğerlerinde de vardır. Yetkiler ise veritabanı nesnelerine bağlı olduğu için veritabanından veritabanına farklılaşır.

initdb ile yeni bir küme kurulduğunda içinde oturum açabilen tek bir rol bulunur ve bu rol her zaman süper kullanıcıdır. Adı, initdb komutunu çalıştıran işletim sistemi kullanıcısının adıdır; çoğu kurulumda bu postgres olur. Başka roller oluşturmak için önce bu rolle bağlanmanız gerekir. Kurulum adımları için initdb ve pg_ctl yazısına göz atabilirsiniz.

CREATE ROLE ve CREATE USER ile rol oluşturma

İki komut aynı işi yapar; tek fark varsayılan değerdedir. CREATE USER, LOGIN özniteliğini kendiliğinden ekler, CREATE ROLE eklemez. Aşağıdaki örnekte biri grup, ikisi kullanıcı olmak üzere üç rol oluşturuyoruz ve psql'in \du komutuyla listeliyoruz:

CREATE ROLE muhasebe;
CREATE USER ayse PASSWORD 'Gizli-Parola-1';
CREATE ROLE mehmet LOGIN CREATEDB CONNECTION LIMIT 3 VALID UNTIL '2027-06-30 23:59:59+03';
\du

                             List of roles
 Role name |                         Attributes                         
-----------+------------------------------------------------------------
 ayse      | 
 mehmet    | Create DB                                                 +
           | 3 connections                                             +
           | Password valid until 2027-06-30 23:59:59+03
 muhasebe  | Cannot login
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS

ayse satırının boş görünmesi bir hata değildir: psql yalnızca varsayılandan farklı öznitelikleri yazar ve LOGIN artık CREATE USER için varsayılandır. muhasebe için yazan Cannot login ise bu rolün yalnızca grup olarak kullanılacağını gösterir. Aynı bilgiyi SQL ile görmek isterseniz pg_roles görünümünü sorgularsınız:

SELECT rolname, rolcanlogin, rolinherit, rolcreatedb, rolconnlimit, rolvaliduntil
FROM pg_roles WHERE rolname IN ('muhasebe', 'ayse', 'mehmet') ORDER BY rolname;

 rolname  | rolcanlogin | rolinherit | rolcreatedb | rolconnlimit |     rolvaliduntil      
----------+-------------+------------+-------------+--------------+------------------------
 ayse     | t           | t          | f           |           -1 | 
 mehmet   | t           | t          | t           |            3 | 2027-06-30 23:59:59+03
 muhasebe | f           | t          | f           |           -1 | 
(3 rows)

rolconnlimit değerindeki -1 sınırsız anlamına gelir ve varsayılandır. Rol adları SQL tanımlayıcı kurallarına uyar: tırnaksız yazarsanız küçük harfe çevrilir, büyük harf ya da özel karakter kullanmak isterseniz çift tırnak gerekir. Kabuktan çalışmayı tercih ederseniz createuser ve dropuser programları aynı SQL komutlarını sizin yerinize çalıştırır.

Rol öznitelikleri tek tek

Öznitelikler, bir rolün nesnelerden bağımsız olarak sahip olduğu özel haklardır. Hepsi CREATE ROLE sırasında ya da sonradan ALTER ROLE ile verilebilir ve her birinin NO önekli bir karşıtı vardır (NOLOGIN, NOCREATEDB gibi).

SUPERUSER en tehlikeli özniteliktir. Belgeler, günlük işlerin süper kullanıcı olmayan bir rolle yapılmasını açıkça önerir; yeni bir süper kullanıcıyı da ancak mevcut bir süper kullanıcı oluşturabilir. CREATEROLE ise sanıldığından daha sınırlıdır: bu öznitelikle süper kullanıcı oluşturamaz, mevcut süper kullanıcılara dokunamaz, REPLICATION ve BYPASSRLS özniteliklerini veremez ya da geri alamazsınız. Süper kullanıcı olmayan bir CREATEROLE rolü yeni bir rol oluşturduğunda, oluşturulan rol kendisine ADMIN seçeneğiyle ama INHERIT FALSE ve SET FALSE ile otomatik olarak verilir. Böylece yönetici, oluşturduğu rolleri değiştirip silebilir, fakat o rollerin tablo yetkilerini kendiliğinden kullanamaz.

REPLICATION özniteliği de belgelerde çok yüksek ayrıcalıklı olarak tanımlanır ve yalnızca gerçekten replikasyon için kullanılan rollere verilmelidir; ayrıca böyle bir rolün LOGIN özniteliğine de ihtiyacı vardır. Uygulamada bu, streaming replication kurulumunda standby sunucunun bağlandığı roldür. BYPASSRLS ise yalnızca süper kullanıcılar ya da kendisi bu özniteliğe sahip roller tarafından verilebilir ve satır düzeyi güvenlik politikalarının tamamını devre dışı bırakır.

CONNECTION LIMIT yaklaşık olarak uygulanır: son bir bağlantı hakkı kalmışken iki oturum aynı anda açılmaya çalışırsa ikisi de reddedilebilir. Hazırlanmış transaction'lar ve arka plan işçileri bu sayıya dahil edilmez, süper kullanıcılar için de sınır hiç uygulanmaz. VALID UNTIL ise rolün değil yalnızca parolanın süresini belirler; sertifika ya da peer gibi parolasız bir yöntemle bağlanan rol, tarih geçse de oturum açmaya devam eder.

Parola nasıl saklanır: SCRAM ve MD5

Parola, istemci kimlik doğrulama yöntemi parola istediğinde anlam taşır ve işletim sistemi parolasından ayrıdır. PostgreSQL parolayı düz metin olarak hiçbir zaman saklamaz; pg_authid kataloğuna, parolanın ayarlandığı andaki password_encryption değerine göre özetlenmiş hâlde yazar. Varsayılan değer scram-sha-256'dır. Bunu sistem kataloğundan doğrulayabilirsiniz (bu katalog yalnızca süper kullanıcıya açıktır):

SELECT rolname, left(rolpassword, 14) AS sifre_bicimi FROM pg_authid WHERE rolname = 'ayse';
SHOW password_encryption;

 rolname |  sifre_bicimi  
---------+----------------
 ayse    | SCRAM-SHA-256$
(1 row)

 password_encryption 
---------------------
 scram-sha-256
(1 row)

MD5 ile saklanan parolalar PostgreSQL 18 sürüm notlarında kullanımdan kaldırılmış (deprecated) olarak işaretlendi ve gelecekteki bir ana sürümde tamamen kaldırılacak. PostgreSQL 18'de CREATE ROLE ve ALTER ROLE bir MD5 parolası ayarlarken uyarı verir. Bunu bilerek denedik:

SET password_encryption = 'md5';
CREATE ROLE gecici LOGIN PASSWORD 'eski-usul';

WARNING:  setting an MD5-encrypted password
DETAIL:  MD5 password support is deprecated and will be removed in a future release of PostgreSQL.
HINT:  Refer to the PostgreSQL documentation for details about migrating to another password type.
CREATE ROLE

Uyarı, md5_password_warnings parametresi off yapılarak susturulabilir, ama doğru çözüm SCRAM'a geçmektir. MD5 özetinde rol adı tuz olarak kullanıldığı için böyle bir rolü yeniden adlandırdığınızda parolası silinir; denediğimizde sunucu NOTICE: MD5 password cleared because of role rename mesajını verdi ve rolpassword değeri null oldu. Belgelerin önerdiği geçiş sırası şöyledir: önce kullanılan bütün istemci kütüphanelerinin SCRAM desteklediğinden emin olun, password_encryption değerini scram-sha-256 yapın, kullanıcıların parolalarını yeniden ayarlatın ve en son pg_hba.conf içindeki yöntemi scram-sha-256 olarak değiştirin. Yöntemlerin ayrıntısı pg_hba.conf yazısında var.

Grup rolleri ve üyelik: INHERIT ve SET seçenekleri

Yetkileri kişilere tek tek vermek yerine bir grup rolüne verip kişileri o gruba üye yapmak yönetimi çok kolaylaştırır. Üyelik GRANT grup TO uye ile eklenir, REVOKE grup FROM uye ile kaldırılır. Döngüsel üyelik kurulamaz ve bir role PUBLIC üye yapılamaz.

PostgreSQL 16'dan önce kalıtım, rol düzeyinde tek bir öznitelikti. Artık her üyelik kaydının kendi seçenekleri vardır: INHERIT açıksa üye, grubun yetkilerini kendiliğinden kullanır; SET açıksa üye SET ROLE grup ile geçici olarak o role bürünebilir; ADMIN açıksa üye bu gruba başkalarını ekleyip çıkarabilir. INHERIT için varsayılan, üye rolün kendi INHERIT özniteliğinden gelir; SET varsayılan olarak açık, ADMIN kapalıdır. Aşağıda bir fatura tablosu oluşturup okuma yetkisini muhasebe grubuna veriyoruz ve üç farklı üyelik tanımlıyoruz:

CREATE TABLE faturalar (no int PRIMARY KEY, musteri text, tutar numeric(10,2));
INSERT INTO faturalar VALUES (1, 'Ankara Kırtasiye', 1250.00), (2, 'İzmir Gıda', 980.50);
GRANT SELECT ON faturalar TO muhasebe;
GRANT muhasebe TO ayse;
CREATE ROLE yonetici CREATEDB;
GRANT yonetici TO ayse WITH INHERIT FALSE;
GRANT muhasebe TO mehmet WITH SET FALSE;
\drg

               List of role grants
 Role name | Member of |   Options    | Grantor  
-----------+-----------+--------------+----------
 ayse      | muhasebe  | INHERIT, SET | postgres
 ayse      | yonetici  | SET          | postgres
 mehmet    | muhasebe  | INHERIT      | postgres
(3 rows)

psql'in \drg komutu her üyeliği seçenekleri ve yetkiyi veren rolle (grantor) birlikte listeler. Şimdi ayse olarak bağlanıp ne olduğuna bakalım:

-- psql -U ayse -d ornek_rol
SELECT current_user, session_user;
SELECT musteri, tutar FROM faturalar ORDER BY no;
CREATE DATABASE ayse_deneme;
SET ROLE yonetici;
SELECT current_user, session_user;
CREATE DATABASE ayse_deneme;
RESET ROLE;

 current_user | session_user 
--------------+--------------
 ayse         | ayse
(1 row)

     musteri      |  tutar  
------------------+---------
 Ankara Kırtasiye | 1250.00
 İzmir Gıda       |  980.50
(2 rows)

ERROR:  permission denied to create database
SET
 current_user | session_user 
--------------+--------------
 yonetici     | ayse
(1 row)

CREATE DATABASE
RESET

Sonuçta üç kural birlikte görünüyor. ayse, muhasebe üyeliği INHERIT ile verildiği için fatura tablosunu hiçbir ek komut olmadan okudu. CREATEDB özniteliğine sahip yonetici rolünün üyesi olmasına rağmen ilk CREATE DATABASE reddedildi, çünkü LOGIN, SUPERUSER, CREATEDB ve CREATEROLE gibi öznitelikler hiçbir zaman kalıtımla geçmez; bunları kullanmak için o role SET ROLE ile geçmek gerekir. SET ROLE sonrasında current_user değişti ama session_user aynı kaldı; bu sırada oluşturulan nesnelerin sahibi de yonetici olur. RESET ROLE ya da SET ROLE NONE ilk duruma döndürür.

SET FALSE ile eklenen mehmet ise tabloyu kalıtım sayesinde okuyabildi, ama role geçmeye çalıştığında reddedildi:

-- psql -U mehmet -d ornek_rol
SELECT count(*) FROM faturalar;   -- sonuç: 2
SET ROLE muhasebe;

ERROR:  permission denied to set role "muhasebe"

Bu kombinasyon, kişinin grup yetkilerini kullanmasını ama grup adına nesne oluşturmasını istemediğiniz durumlarda işe yarar. Bir rolün başka bir role üye olup olmadığını SQL ile kontrol etmek için pg_has_role() fonksiyonu kullanılır: USAGE sorusu yetkilerin şu an kalıtımla kullanılıp kullanılamayacağını, MEMBER sorusu doğrudan ya da dolaylı üyelik olup olmadığını yanıtlar. Örneğimizde pg_has_role('ayse', 'yonetici', 'USAGE') false, aynı soru MEMBER ile true döndü.

Önceden tanımlı roller

PostgreSQL, sık ihtiyaç duyulan ayrıcalıklı işler için hazır roller getirir. Bunları bir kullanıcıya GRANT ile vererek süper kullanıcı yapmadan belirli bir yetki tanımlayabilirsiniz. Belgeler, bu rollerin ayrıcalıklı bilgilere erişim sağladığını ve ancak gerektiğinde verilmesi gerektiğini vurgular; kapsamlarının gelecekteki sürümlerde değişebileceğini de not eder.

Raporlama için salt okunur bir kullanıcıya ihtiyacınız varsa en kısa yol pg_read_all_data rolüdür:

CREATE ROLE raporcu LOGIN;
GRANT pg_read_all_data TO raporcu;
-- psql -U raporcu -d ornek_rol
SELECT musteri FROM faturalar ORDER BY no;
INSERT INTO faturalar VALUES (3, 'Bursa Tekstil', 10);

     musteri      
------------------
 Ankara Kırtasiye
 İzmir Gıda
(2 rows)

ERROR:  permission denied for table faturalar

raporcu tabloya hiçbir GRANT almadan okuyabildi ama yazamadı. Dikkat edilmesi gereken nokta, pg_read_all_data ve pg_write_all_data rollerinin satır düzeyi güvenlik politikalarını atlamamasıdır; RLS kullanan tablolarda bu kullanıcılar da politikaya takılır. Tablo bazında daha ince ayarlı bir salt okunur kullanıcı kurmak isterseniz GRANT ve ALTER DEFAULT PRIVILEGES yazısındaki örneği izleyin. İzleme işleri için pg_monitor rolünün ne gösterdiğini pg_stat_activity yazısında bulabilirsiniz.

ALTER ROLE ile değişiklik ve role özel ayarlar

Bütün öznitelikler sonradan ALTER ROLE ile değiştirilebilir: ALTER ROLE mehmet NOCREATEDB, ALTER ROLE ayse VALID UNTIL 'infinity' ya da ALTER ROLE ayse PASSWORD NULL gibi. Komutun daha az bilinen bir kullanımı, role özel çalışma zamanı ayarlarıdır. ALTER ROLE ad SET parametre = deger ayarı hemen uygulamaz; rol bir sonraki bağlantısında oturum başlar başlamaz SET çalıştırılmış gibi davranır. Kullanıcı oturum içinde bu değeri yine değiştirebilir, yani bu bir zorunluluk değil varsayılandır.

ALTER ROLE mehmet SET search_path = muhasebe_sema, public;
SELECT rolname, rolconfig FROM pg_roles WHERE rolname = 'mehmet';

 rolname |               rolconfig               
---------+---------------------------------------
 mehmet  | {"search_path=muhasebe_sema, public"}
(1 row)

Ayarı kaldırmak için ALTER ROLE mehmet RESET search_path yazarsınız. LOGIN özniteliği olmayan rollere bağlanan ayarlar hiçbir zaman devreye girmez, çünkü o rolle oturum açılmaz. Hangi parametrelerin bu şekilde ayarlanabileceği ve ayarların öncelik sırası postgresql.conf ve ALTER SYSTEM yazısında anlatılıyor.

Rolü silmek: DROP ROLE, REASSIGN OWNED ve DROP OWNED

Rol, sahibi olduğu nesneler ya da kendisine verilmiş yetkiler dururken silinemez. Aşağıda bir tablo oluşturan ve başka bir tabloya yetki almış eski_calisan rolünü silmeye çalışıyoruz:

CREATE ROLE eski_calisan LOGIN;
CREATE ROLE devralan LOGIN;
GRANT CREATE ON SCHEMA public TO eski_calisan;
SET ROLE eski_calisan;
CREATE TABLE stok (urun text, adet int);
RESET ROLE;
GRANT SELECT ON faturalar TO eski_calisan;
DROP ROLE eski_calisan;

ERROR:  role "eski_calisan" cannot be dropped because some objects depend on it
DETAIL:  privileges for schema public
privileges for table faturalar
owner of table stok

Hata mesajı neyin engel olduğunu tek tek sayar. Belgelerdeki genel tarif iki adımdır: önce REASSIGN OWNED ile sahip olunan nesneleri başka bir role devredin, sonra DROP OWNED ile kalan nesneleri ve role verilmiş yetkileri temizleyin. Sıra önemlidir; DROP OWNED önce çalışırsa devretmek istediğiniz nesneler de silinir.

REASSIGN OWNED BY eski_calisan TO devralan;
DROP OWNED BY eski_calisan;
DROP ROLE eski_calisan;
SELECT tableowner FROM pg_tables WHERE tablename = 'stok';

REASSIGN OWNED
DROP OWNED
DROP ROLE
 tableowner 
------------
 devralan
(1 row)

Bu iki komut yalnızca bağlı olduğunuz veritabanında çalışır. Rolün başka veritabanlarında da nesnesi ya da yetkisi varsa her birine bağlanıp aynı iki adımı tekrarlamanız gerekir. İlk REASSIGN OWNED, kümeye ait paylaşılan nesnelerin (veritabanları ve tablespace'ler) sahipliğini de devreder. DROP OWNED ise veritabanı ve tablespace silmez; bunları elle halletmelisiniz. Bir grup rolü silindiğinde üyelikler kendiliğinden kaldırılır, üye roller başka bir şekilde etkilenmez.

Sık yapılan hatalar

• Grup rolüyle bağlanmaya çalışmak: CREATE ROLE ile oluşturulan rol varsayılan olarak NOLOGIN'dir. Bağlanmayı denediğimizde psql FATAL: role "muhasebe" is not permitted to log in verdi. Kullanıcı için CREATE USER ya da LOGIN kullanın.
• CREATEDB'nin üyelikle geçeceğini sanmak: öznitelikler kalıtımla geçmez; ya kullanıcıya doğrudan verin ya da SET ROLE ile o role geçin.
• Uygulamayı süper kullanıcıyla çalıştırmak: süper kullanıcı RLS dahil her kontrolü atlar. Uygulamaya yalnızca ihtiyaç duyduğu yetkileri taşıyan bir LOGIN rolü verin.
• VALID UNTIL ile hesabı kapattığını düşünmek: yalnızca parolanın süresi dolar. Rolün bağlanmasını kesin olarak engellemek için ALTER ROLE ad NOLOGIN kullanın.
• DROP OWNED'ı REASSIGN OWNED'dan önce çalıştırmak: devretmek istediğiniz tablolar da silinir. Önce devir, sonra temizlik.
• Parolayı komut satırında açık yazmak: komut geçmişine ve günlüğe düşebilir; \password kullanın.

Sık Sorulan Sorular

CREATE USER ile CREATE ROLE arasında ne fark var?

Tek fark CREATE USER komutunun LOGIN özniteliğini varsayılan olarak eklemesidir. Diğer bütün seçenekler aynıdır ve iki komut da aynı türde bir rol nesnesi oluşturur.

Bir rol yalnızca tek bir veritabanına mı aittir?

Hayır. Roller küme düzeyindedir ve sunucudaki her veritabanında görünür. Bir rolün hangi veritabanına bağlanabileceğini CONNECT yetkisi ve pg_hba.conf kuralları belirler; ayrıntılar GRANT yazısında ve pg_hba.conf yazısında.

Kullanıcının parolasını nasıl değiştiririm?

Süper kullanıcı her rolün, CREATEROLE özniteliğine sahip bir rol ise ADMIN yetkisi olduğu rollerin parolasını ALTER ROLE ad PASSWORD '...' ile değiştirebilir; sıradan roller yalnızca kendi parolalarını değiştirebilir. Parolanın günlüğe düşmemesi için psql'de \password ad tercih edin.

Süper kullanıcı vermeden başka oturumları sonlandırma yetkisi verebilir miyim?

Evet, GRANT pg_signal_backend TO kullanici yeterlidir. Bu rol süper kullanıcıya ait oturumlara sinyal gönderemez. Sorgu iptali ve oturum sonlandırma fonksiyonları izleme yazısında anlatılıyor.

MD5 parolalı eski kullanıcıları nasıl bulurum?

Süper kullanıcı olarak SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%' sorgusu MD5 ile saklanmış parolaları listeler. Bu kullanıcıların parolasını password_encryption değeri scram-sha-256 iken yeniden ayarlatmanız yeterlidir.

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 · PostgreSQL GRANT ve REVOKE · pg_hba.conf ve uzak bağlantı · Row level security · postgresql.conf ve ALTER SYSTEM · PostgreSQL nedir?