Linux Dosya İzinleri: chmod, chown, SUID/SGID, ACL ve capabilities

Linux Dosya İzinleri: chmod, chown, SUID/SGID, ACL ve capabilities

Linux'ta "neden olmuyor" sorusunun yarısı izin sorunudur. Site açılmıyor, çünkü Apache dosyayı okuyamıyor. Script çalışmıyor, çünkü execute biti yok. WordPress upload hata veriyor, çünkü wp-content/uploads/ dizini doğru sahipte değil. cron tetiklenmiyor, çünkü çalıştırılabilir değil. Bu rehber Linux dosya izin sistemini — yani DAC (Discretionary Access Control) modelini — sıfırdan, üretim ortamı gözüyle anlatır: klasik UNIX rwx, octal (sayısal) ve symbolic (sembolik) chmod, sahiplik (chown + chgrp), özel izin bitleri (SUID / SGID / sticky), POSIX ACL ile UNIX modunun ötesine geçme, modern alternatif Linux capabilities, umask ile yeni dosya varsayılanları, ve son olarak WordPress / Apache / Nginx / cPanel CageFS ortamlarında doğru izin pratikleri.

Buyukweb perspektifi: cPanel paketlerimizde (₺350-2.000/yıl aralığı) CloudLinux + CageFS + LVE standart gelir; her cPanel kullanıcısı kendi chroot-benzeri sanal dosya sistemi içinde yaşar, /usr/bin ve /etc gibi sistem dizinleri kullanıcıya filtrelenmiş görünür. VDS sunucularımızda (E5-V4) ise root erişim sizdedir; izin politikası tamamen sizin elinizde — kernel düzeyinde chmod, setfacl, setcap her şey serbest. Yanlış konfigürasyon (özellikle chmod -R 777) güvenlik açığı yaratır; bu rehberi pratik bir başvuru olarak yanınızda tutun. Bursa Tier 3 veri merkezi, 0850 302 60 70 destek hattı.

Linux DAC (Discretionary Access Control) Modeli

Linux'un dosya erişim kontrolü iki ana modelde çalışır:

• DAC (Discretionary Access Control) — Dosyanın sahibi izin verir. Klasik UNIX modu (rwxr-xr-x), POSIX ACL, capabilities ve umask hep bu modelde. Sahibi olduğunuz bir dosyada izinleri istediğiniz gibi değiştirebilirsiniz.
• MAC (Mandatory Access Control) — Sistem yöneticisi izin verir, kullanıcı kendi başına değiştiremez. SELinux, AppArmor, smack bu kategoride. CIS Benchmark sertli sunucularda DAC üzerine MAC ek katman olarak çalışır.

Bu rehber DAC'a odaklanır. MAC tarafı için CIS Benchmark rehberimize (Linux CIS Benchmark Sertleştirme) bakabilirsiniz; SELinux file context (semanage fcontext, restorecon) DAC izinlerinin yanı sıra ayrı bir kontrol katmanıdır.

Kernel'in karar mantığı çok basittir:

1. İşlem dosyaya erişmek ister.
2. Kernel önce işlemin efektif UID'i ile dosyanın sahip UID'i eşit mi diye bakar. Eşitse "owner" izinleri (rwx------ ilk üç bit) uygulanır.
3. Değilse, işlemin efektif GID veya supplementary group'larından biri dosyanın grup GID'i ile eşit mi diye bakar. Eşitse "group" izinleri (orta üç bit) uygulanır.
4. Hiçbiri değilse "other" izinleri (son üç bit) uygulanır.
5. root (UID 0) bütün bu kuralları bypass eder — istisna: capabilities ile bazı sınırlar konabilir.

Bu karar tek tek bit kontrolüdür; çok hızlıdır (mikrosaniye). Modern Linux'ta milyarlarca dosyada bu yöntem ölçeklenir.

ls -l Çıktısı Anatomi

İzin sistemini görmek için ilk komut ls -l. Tipik çıktı:

-rw-r--r--  1 alperen www-data  4096 May  9 14:32 index.html
drwxr-xr-x  3 alperen www-data  4096 May  9 14:31 wp-content
-rwsr-xr-x  1 root    root     54256 Jan  5  2024 /usr/bin/passwd
lrwxrwxrwx  1 root    root         9 Jan  5  2024 link.html -> index.html

Her sütunu inceleyelim:

Karakter	Anlam
1.	Dosya tipi: - normal dosya, d dizin, l symlink, b block device, c character device, p named pipe (FIFO), s socket
2-4	Owner (sahip) izinleri: r oku, w yaz, x çalıştır
5-7	Group (grup) izinleri
8-10	Other (diğer/dünya) izinleri
11. (varsa)	Genişletilmiş özellik göstergesi: . SELinux label, + POSIX ACL var
Sayı	Hard link sayısı (dizinler için . ve .. da sayılır)
Sütun 3	Owner kullanıcı adı
Sütun 4	Group adı
Sütun 5	Boyut (byte)
Sütun 6-8	Son değiştirilme zamanı
Sütun 9	Dosya/dizin adı

index.html için -rw-r--r--: normal dosya, owner okur+yazar, group sadece okur, other sadece okur. Web sunucusu varsayılan WordPress dosyası — Apache muhtemelen www-data grubu içinde olduğu için r ile içeriği okur ve sunar.

/usr/bin/passwd için -rwsr-xr-x: dikkat ederseniz owner execute bitinde x yerine s var — bu SUID bayrağıdır (aşağıda). Bu nedenle sıradan kullanıcı passwd çalıştırınca işlem root UID'i ile koşar; sadece bu yüzden /etc/shadow dosyasına yazabilir.

link.html için lrwxrwxrwx: l symlink, izinler hep 777 görünür ama gerçek erişim hedef dosyanın izinlerine göre belirlenir.

Octal (Numeric / Sayısal) Gösterim

UNIX izinlerini en hızlı kavramanın yolu octal (8'lik tabanda) düşünmektir. Her izin bir bittir:

Bit	Değer
r (read)	4
w (write)	2
x (execute)	1

Üçü toplanır:

Octal	Binary	Symbolic	Anlam
7	111	rwx	hepsi
6	110	rw-	oku+yaz
5	101	r-x	oku+çalıştır
4	100	r--	sadece oku
3	011	-wx	yaz+çalıştır (nadir, anlamsız genellikle)
2	010	-w-	sadece yaz (nadiren)
1	001	--x	sadece çalıştır
0	000	---	hiçbiri

Sonra owner / group / other için üç octal rakam yan yana yazılır:

Octal	Symbolic	Tipik Kullanım
755	rwxr-xr-x	Çalıştırılabilir dosya, web dizini, public script
644	rw-r--r--	HTML, CSS, JS, config (okunabilir), text dosya
600	rw-------	SSH özel anahtarı, hassas config (sadece owner)
640	rw-r-----	Owner + grup okur, others yok (log, sertifika)
700	rwx------	Owner-only çalıştırılabilir / dizin, ~/.ssh
750	rwxr-x---	Owner full, grup oku+çalıştır, others yok
711	rwx--x--x	Owner full, diğerleri sadece "geçer" (dizin için: girer ama listelemez)
775	rwxrwxr-x	Owner + grup yazabilir, web dev paylaşımlı dizin
777	rwxrwxrwx	Tehlikeli — herkes her şey yapabilir; üretimde kullanmayın

Yaygın hata: "WordPress upload hata veriyor" çözümü olarak chmod -R 777 /var/www/html yapmak. Asla. Bu komut tüm WordPress dosyalarını dünyaya yazılır kılar; bir başka kiracının (paylaşımlı) ya da exploit edilmiş bir başka servisin (VDS) dosyanıza yazıp PHP backdoor enjekte etmesi için resmi davet olur. Doğru çözüm dizin için 755, dosya için 644, sahiplik www-data (Apache/Nginx kullanıcısı).

chmod — Octal Mod

chmod (change mode) komutu izinleri değiştirir. İki kullanım vardır: octal ve symbolic.

# Octal mod — tam izin yazimi
chmod 644 index.html              # rw-r--r--
chmod 755 deploy.sh               # rwxr-xr-x
chmod 600 ~/.ssh/id_ed25519       # rw------- (SSH ozel anahtari icin ZORUNLU)
chmod 700 ~/.ssh                  # rwx------ (SSH dizini)
chmod 750 /var/log/myapp          # rwxr-x---

Octal mod kesin, deterministik — istediğiniz tam izni yazar, mevcut izni bilmenize gerek yoktur. Script otomasyonunda tercih edilir.

chmod — Symbolic Mod

Symbolic mod göreceli değişiklik yapar. Üç parça vardır: kim (who), operatör (op), izin (perm).

Kim (who)	Anlam
u	user/owner
g	group
o	others
a	all (u + g + o)

Operatör	Anlam
+	ekle
-	çıkar
=	tam olarak ata (varsa kaldır)

Perm	Anlam
r	read
w	write
x	execute
X	execute (sadece dizin veya zaten en az birinde x olan dosyalara — recursive için süper güvenli)
s	SUID veya SGID (kullanım yerine göre)
t	sticky

Pratik örnekler:

chmod u+x deploy.sh                # owner'a x ekle
chmod g+w shared.log               # gruba w ekle
chmod o-r config.php               # others'tan r kaldir
chmod a-x dangerous.sh             # herkesten x kaldir
chmod u=rw,g=r,o= secret.txt       # owner rw, group r, others hicbir sey
chmod u+rwx,g+rx,o+rx script.sh    # 755 ile esdeger
chmod g=u file                     # grup izinlerini owner'inkine esitle
chmod -R u+rwX,g+rX,o+rX /var/www  # recursive: dizinler 755 dosyalar 644 olur (X capital)

X (capital) çok faydalı: recursive bir chmod yaparken dizinleri çalıştırılabilir (girilebilir) yapar, dosyalara x eklemez — sadece halihazırda en az bir kategoride x olan dosyalara ekler. Düz -R +x her dosyayı çalıştırılabilir yapar (hata, gereksiz .html çalıştırılabilir olmaz mantıklı).

chmod -R Recursive Tuzak

Şu chmod -R 755 /var/www komutu dizinler için doğru (755 = girilebilir + okunabilir), dosyalar için yanlış (her .html çalıştırılabilir olmamalı; .php belki ama HTML değil). Bunu önlemek için find ile ayır:

# Dizinler 755, dosyalar 644
find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;

# Daha hizli: + ile xargs benzeri toplu calistirma
find /var/www -type d -exec chmod 755 {} +
find /var/www -type f -exec chmod 644 {} +

# Tek satirda: parantez gruplandirma
find /var/www \( -type d -exec chmod 755 {} + \) -o \( -type f -exec chmod 644 {} + \)

# Veya X kullan (capital X — dizin ve halihazirda x olan dosyaya x ekler)
chmod -R u=rwX,g=rX,o=rX /var/www

İlk find çağrısında -exec chmod {} \; her dosya için ayrı chmod çağırır (yavaş). {} + toplu çağrı yapar (hızlı). Büyük dosya ağaçlarında 10-100x fark olur.

chown — Sahip ve/veya Grup Değiştir

chown alperen file.txt                          # sahip alperen, grup degismez
chown alperen:devs file.txt                     # sahip alperen, grup devs
chown :devs file.txt                            # sadece grup devs
chown -R www-data:www-data /var/www/html        # recursive (KRITIK WordPress)
chown --reference=src.txt dst.txt               # src.txt'in sahip+grup'unu dst.txt'e kopyala
chown -h alperen symlink                        # symlink kendisinin (hedef dosyanin DEGIL) sahibini degistir

chown'u sadece root çalıştırabilir. Sıradan kullanıcı kendi dosyasının sahipliğini bile başkasına devredemez (POSIX semantiği — quota bypass'ını önler).

chgrp — Sadece Grup Değiştir

chgrp chown :grupadi ile aynı işi yapar; sözdizimi sade:

chgrp devs file.txt                  # grup devs
chgrp -R www-data /var/www/html      # recursive
chgrp --reference=src.txt dst.txt    # src.txt grubunu dst.txt'e kopyala

Modern pratikte chown :grupadi daha yaygındır; chgrp tarihsel bir yardımcı olarak duruyor.

find ile Toplu İzin Yönetimi

Geniş dizin ağaçlarında izin denetimi ve düzeltmesi için find vazgeçilmezdir. Tipik kalıplar:

# SUID bayrakli tum dosyalari bul (audit)
find / -perm -4000 -type f 2>/dev/null

# SGID bayrakli
find / -perm -2000 -type f 2>/dev/null

# Sticky bit dizinler (/tmp gibi)
find / -perm -1000 -type d 2>/dev/null

# Dunya yazilabilir dosyalar (TEHLIKE)
find / -type f -perm -o+w 2>/dev/null

# Dunya yazilabilir dizinler ama sticky DEGIL (cift tehlike)
find / -type d -perm -o+w ! -perm -1000 2>/dev/null

# Sahipsiz dosyalar (UID/GID gecmiste silinmis kullaniciya ait)
find / -nouser 2>/dev/null
find / -nogroup 2>/dev/null

# Modu tam olarak 777 olan dosyalar
find /var/www -type f -perm 777

# Son 1 saatte degisen dosyalar
find /var/www -type f -mmin -60

# 30 gun once degisen + 644 olmayan dosyalar (audit kombinasyon)
find /var/www -type f -mtime -30 ! -perm 644 -ls

Bu komutlar CIS Benchmark, ISO 27001 veya PCI-DSS audit'lerinde sık koşulur. Buyukweb VDS'te düzenli find / -perm -4000 -type f -ls çıktısı saklayıp yeni SUID dosya tespiti otomatize edebilirsiniz — sonradan eklenen bir SUID dosya rootkit göstergesi olabilir.

Özel İzin Bitleri — SUID, SGID, Sticky

Klasik UNIX modu 9 bittir (3x3 = owner/group/other × rwx); ama gerçekte 12 bit vardır. Yüksek 3 bit özel davranışları kontrol eder:

Bit	Octal	Symbolic Yer	Anlam
SUID	4000	owner x yerinde s	Çalıştırılan dosya dosya sahibinin UID'i ile koşar
SGID	2000	group x yerinde s	Dosyada: grup GID; Dizinde: yeni dosya o grubun olur
Sticky	1000	other x yerinde t	Dizinde: sadece dosyanın sahibi silebilir

SUID (Set-User-ID) — 4000

/usr/bin/passwd klasik SUID örneğidir:

ls -l /usr/bin/passwd
# -rwsr-xr-x  1 root root  54256 Jan  5  2024 /usr/bin/passwd

s (owner execute yerinde) demek ki sıradan bir kullanıcı passwd çalıştırınca işlem root UID'i ile koşar — bu nedenle /etc/shadow (mod 0640, owner root) dosyasına yazabilir. SUID olmasaydı kullanıcı kendi parolasını değiştiremezdi.

Tipik SUID dosyalar: /usr/bin/passwd, /usr/bin/sudo, /usr/bin/su, /usr/bin/mount, /usr/bin/chsh, /usr/bin/newgrp, /usr/bin/ping (eski sistemlerde; modern Linux'ta capability ile değiştirildi).

Atama:

chmod 4755 /usr/local/bin/myhelper       # SUID + 755
chmod u+s   /usr/local/bin/myhelper      # symbolic
chmod u-s   /usr/local/bin/myhelper      # kaldir

SGID (Set-Group-ID) — 2000

İki ayrı anlamı vardır:

Dosyada: İşlem dosyanın grubu ile koşar. Örnek: /usr/bin/wall (tty grubu ile koşar, tüm terminallere yazabilmek için).

Dizinde (DAHA YAYGIN VE YARARLI): Bu dizinde yeni oluşturulan her dosya/alt dizin otomatik olarak dizinin grubunu alır. Paylaşımlı dizinlerde inanılmaz pratik. Örnek:

mkdir /srv/proje
chgrp devs /srv/proje
chmod 2775 /srv/proje                    # SGID + rwxrwxr-x
# Artik /srv/proje icinde olusturulan her dosya/dizin grup "devs" olur
# Birden cok dev kullanicisi sorunsuz paylasir

Atama:

chmod 2755 dir                           # SGID + 755
chmod g+s dir                            # symbolic
chmod g-s dir                            # kaldir

Sticky Bit — 1000

Klasik anlam (eski UNIX): metin segmentini swap'ta tut — modern Linux'ta önemsiz. Modern Linux'ta sticky sadece dizinler için anlamlıdır:

Bir dizin sticky ise, içindeki dosyaları sadece dosyanın sahibi (veya dizinin sahibi veya root) silebilir. Yani dizin world-writable olsa bile kimse başkasının dosyasını silemez.

Klasik örnek /tmp:

ls -ld /tmp
# drwxrwxrwt  20 root root  4096 May  9 14:35 /tmp

t other execute yerindedir → sticky bayrağı aktif. /tmp mod 1777; herkes okur, yazar, çalıştırır ama sadece kendi dosyalarını siler. Bu olmasaydı bir kullanıcı /tmp'deki başka kullanıcının session dosyalarını silip oturum çökertebilirdi.

Atama:

chmod 1777 /shared                       # sticky + 777
chmod +t /shared                         # symbolic
chmod -t /shared                         # kaldir

Yüksek Octal Birleşimleri

Üç özel bit birleşik:

Octal	Anlam
4755	SUID + rwxr-xr-x (klasik SUID binary)
2755	SGID + rwxr-xr-x (klasik SGID binary)
2775	SGID + rwxrwxr-x (paylaşımlı grup dizini)
1777	Sticky + rwxrwxrwx (paylaşımlı /tmp benzeri)
6755	SUID + SGID + rwxr-xr-x (nadir; çok kapsamlı)
7775	Hepsi (kullanmayın — anlamsız ve tehlikeli)

SUID/SGID Güvenlik Riskleri

SUID dosya bulan saldırgan dosya sahibinin yetkisini ödünç alır. Eğer dosya root SUID ise → bir buffer overflow / komut enjeksiyonu → tüm sistem root. Bu nedenle SUID dosyalar azaltılmalı:

• Yeni paket kurarken find / -perm -4000 -type f çıktısını karşılaştırın.
• Custom yazdığınız script'leri asla SUID yapmayın (shell SUID = anında root exploit yolu — kernel modern olarak shell script'lerin SUID bitini ignore eder, ama C wrapper ile yine de yapılabilir).
• Mümkünse capabilities ile değiştirin (aşağıda).

cPanel / CageFS ortamında SUID dosya listesi filtrelenir: CageFS proxy'lemediği SUID dosyaları kullanıcıya görünmez. getsebool veya getcap tabanlı çözümler tercih edilir.

POSIX ACL (Access Control Lists)

Klasik UNIX modu üç entity ile sınırlı: owner, group, other. "Hem developer grubu hem ayrıca Alice ve Bob okusun, başka kimse okumasın" gibi senaryolar için yetersiz. POSIX ACL bu boşluğu doldurur.

Modern filesystem'ler (ext4, xfs, btrfs) varsayılan olarak acl özelliği ile mount edilir. ext4'te 2.6.42 sonrası kernel built-in; manuel mount opsiyonu gerekmez.

getfacl — ACL Görüntüle

getfacl /var/log/myapp/app.log
# file: var/log/myapp/app.log
# owner: alperen
# group: devs
# user::rw-
# user:alice:rw-                              # ozel Alice izni
# group::r--
# group:auditors:r--                          # ozel auditors grubu izni
# mask::rw-                                   # azami efektif izin
# other::---

mask ACL'in özel parçasıdır: named user / named group / group entry'lerinin azami efektif iznini belirler. mask rw ise ve alice rwx atanmışsa, alice'in efektif izni rw olur.

setfacl — ACL Ata

# Alice'e rw izni ekle
setfacl -m u:alice:rw file.txt

# Grup auditors'a r izni ekle
setfacl -m g:auditors:r file.txt

# Birden fazla satir tek komutta
setfacl -m u:alice:rw,u:bob:r,g:auditors:r file.txt

# Recursive
setfacl -R -m u:alice:rw /var/log/myapp

# Bir entry'yi kaldir
setfacl -x u:alice file.txt

# Tum ACL'leri sifirla (klasik mode'a don)
setfacl -b file.txt

Default ACL — Yeni Dosyalar Otomatik Miras

Dizin için default ACL atayabilirsiniz; o dizinde yeni oluşturulan dosyalar otomatik olarak bu ACL'i miras alır:

mkdir /srv/shared
setfacl -d -m u:alice:rwx /srv/shared        # default: yeni dosyalarda Alice rwx
setfacl -d -m g:devs:rx /srv/shared          # default: yeni dosyalarda devs grubu rx

touch /srv/shared/test.txt
getfacl /srv/shared/test.txt
# user:alice:rwx ve group:devs:rx otomatik mevcut

Default ACL paylaşımlı dizinler (CI/CD artifact, log collection) için altın değerinde. SGID dizin + default ACL kombosu bir ekibin sürtünmesiz çalışması için yeterli.

ACL'in Var Olduğunu Nasıl Anlarsınız?

ls -l çıktısının mod karakterinin sonunda + varsa o dosyada ek ACL var:

ls -l file.txt
# -rw-rw----+  1 alperen devs  4096 May  9 14:32 file.txt
#         ^ + isareti = ACL var

Filesystem Mount Option

ext4 varsayılan, manuel ayar gerekmez. xfs için de varsayılan. Eski dağıtımda mount -o remount,acl / gerekebilir; modern Buyukweb VDS imajlarında (AlmaLinux 9, Ubuntu 22.04+, Debian 12) acl başlangıçta aktif.

Linux Capabilities — Modern Alternatif SUID'e

SUID büyük çekiç: dosya sahibi yetkisinin tamamı ödünç verilir. Bir ping programı root SUID ile koşmasın diye — ping'in tek ihtiyacı SOCK_RAW socket açma yeteneği (port < 1024 değil aslında). Modern Linux capabilities ile bu yetenekleri ince ince ayırır; bir programa "sadece bu kabiliyet" verirsiniz.

Yaygın Capabilities

Capability	Anlam
CAP_NET_BIND_SERVICE	< 1024 portlara bind edebilme (80, 443)
CAP_NET_RAW	Raw socket (ping, tcpdump için)
CAP_DAC_OVERRIDE	Dosya izinlerini bypass (root benzeri)
CAP_DAC_READ_SEARCH	Dosya izinlerini okuma için bypass
CAP_CHOWN	Dosya sahipliği değiştirme
CAP_FOWNER	Sahip olmadığı dosyayı sahip gibi işlem
CAP_KILL	Başka UID'in process'ini öldürme
CAP_NET_ADMIN	Ağ yapılandırma (route, firewall)
CAP_SYS_ADMIN	Çok geniş — neredeyse root (mount, namespace, vb.)
CAP_SYS_TIME	Sistem saatini değiştirme
CAP_SETUID	UID değiştirme yetkisi
CAP_AUDIT_WRITE	Audit log yazma

Tam liste: man 7 capabilities — 40+ capability var. CAP_SYS_ADMIN "kötü adam capability" olarak bilinir; bir saldırgan bunu ele geçirirse hemen hemen root oldu sayılır.

setcap / getcap

# Bir binary'ye CAP_NET_BIND_SERVICE ekle (port 80 bind icin)
setcap 'cap_net_bind_service=+ep' /usr/local/bin/myserver

# Goruntule
getcap /usr/local/bin/myserver
# /usr/local/bin/myserver = cap_net_bind_service+ep

# Kaldir
setcap -r /usr/local/bin/myserver

# Tum dosyalara recursive (audit icin)
getcap -r /usr/bin 2>/dev/null

+ep = "effective + permitted". Mode'lar: e (effective), p (permitted), i (inheritable). En yaygın +ep — exec edildiğinde anında aktif.

Pratik Örnek: nginx Port 80 Bind

Bir Node.js / Python web server'ı root olmadan port 80 dinlemek için:

setcap 'cap_net_bind_service=+ep' /usr/bin/node
# Artik Node.js port 80'e root olmadan bind edebilir

# Veya Python (interpreter'a, dikkatli — tum Python scriptlerini etkiler)
setcap 'cap_net_bind_service=+ep' /usr/bin/python3

Daha iyi pratik: web server'ı systemd ile çalıştırın ve AmbientCapabilities=CAP_NET_BIND_SERVICE ekleyin — interpreter binary'sini değiştirmek gerekmez.

# /etc/systemd/system/myapp.service
[Service]
ExecStart=/usr/bin/node /srv/app/server.js
User=myapp
Group=myapp
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

NoNewPrivileges=true capability genişletmesini bloklar — saldırı yüzeyini iyice daraltır.

capsh — Capability Listele

capsh --print
# Current: cap_net_bind_service+ep
# Bounding set: cap_chown,cap_dac_override,cap_dac_read_search,...
# Securebits: 00/0x0/1'b0
# Current IAB: !cap_setuid,!cap_setgid

Bir process'in hangi capability'lerle koştuğunu görmek için grep Cap /proc/<pid>/status da kullanılır.

umask — Yeni Dosya Varsayılan İzni

Bir dosya/dizin oluşturulduğunda hangi izin alır? Cevap: open() syscall'a verilen mode argümanı eksi process'in umask değeri.

Object	Sistem Varsayılanı	umask 022 ile	umask 002 ile	umask 077 ile
Dosya	0666	0644	0664	0600
Dizin	0777	0755	0775	0700

Mantık: umask çıkarılır. 0666 - 0022 = 0644 (rw-r--r--).

Yaygın umask Değerleri

umask	Anlam	Senaryo
022	Owner full, group + other read-only	Klasik UNIX, çoğu dağıtımın varsayılanı
002	Owner full, group full, other read-only	Ekip içi paylaşım (developer grubu yazsın)
077	Sadece owner	Hassas kullanıcı, kişisel sunucu, root için ideal
027	Owner full, group read-only, other yok	Şirket içi sıkı varsayılan
007	Owner full, group full, other yok	Tam grup paylaşımı

umask Nerede Ayarlanır?

Process inheritance ile çalışır — login shell'in umask değeri başlatılan her programa miras kalır.

# Mevcut umask gor
umask
# 0022

# Symbolic format
umask -S
# u=rwx,g=rx,o=rx

# Yeni umask (sadece bu shell)
umask 027

Kalıcı:

• Per-user: ~/.bashrc veya ~/.profile içinde umask 027.
• System-wide: Modern dağıtımlarda /etc/login.defs içinde UMASK 022 (PAM tarafından login zamanı uygulanır), Debian/Ubuntu'da /etc/profile ya da /etc/login.defs, RHEL'de /etc/profile.d/*.sh.
• systemd service: UMask=0027 direktifi [Service] bloğuna konabilir.

Pratik

WordPress / web app dağıtımlarında umask 022 standart — uploads dizininde 755 dizin, 644 dosya isteniyor (Apache okur). Ekip içi shared dev sunucusunda umask 002 + SGID dizin + grup üyeliği — sürtünmesiz dosya paylaşımı.

Symlink ve Hard Link İzinleri

ln -s target.txt link.txt              # symbolic link
ln target.txt hard.txt                 # hard link

ls -l link.txt
# lrwxrwxrwx  1 alperen alperen  10 May  9 ... link.txt -> target.txt

ls -l hard.txt
# -rw-r--r--  2 alperen alperen  4096 May  9 ... hard.txt
#               ^ 2 hard link count

Symlink her zaman lrwxrwxrwx (777) görünür — symlink'in kendi izinleri anlamsızdır, gerçek erişim hedef dosyanın izinlerine göre belirlenir. chmod symlink'e uygulandığında hedef dosyaya gider; symlink kendisini etkilemez (modern Linux'ta chmod -h veya chmod -P ile de çoğu zaman pas geçilir).

Hard link bir inode'a ikinci bir isimdir; her iki isim de aynı dosyadır, izinler birdir. Hard link sayısı ls -l'in 2. sütununda görünür (yukarıda 2). Bir hard link silindiğinde inode kalır; ancak son referans silindiğinde inode disk'ten kaldırılır.

umask, ACL, Capabilities — Birlikte Çalışırlar

Linux DAC çok katmanlıdır. Bir dosyaya erişim kontrolünde sıra şudur:

1. Root (UID 0) hemen hemen her şeyi yapar — capabilities ile kısıtlanmadıkça.
2. Capabilities — process'in capability bounding set'i kontrol edilir.
3. POSIX ACL — varsa, klasik mod'un yerine geçer (mask ile sınırlı).
4. Klasik UNIX mode — owner / group / other × rwx.
5. umask — sadece yeni dosya oluşturulurken etkili.
6. SELinux / AppArmor (MAC) — DAC üstünde ek katman (yukarıdaki her şey "izin ver" derse bile MAC reddedebilir).

Audit ederken hepsini birlikte kontrol edin: ls -l (mod), getfacl (ACL), getcap (capabilities), ls -Z (SELinux context).

WordPress / Apache / Nginx — Önerilen İzinler

Üretim ortamı için en sık karşılaşılan senaryo: WordPress + Apache veya Nginx + PHP-FPM. Doğru izin pratiği:

Standart WordPress + Apache (cPanel veya VDS)

# Owner: site dosyalarini deploy eden kullanici
# Group: web server kullanicisi (www-data Debian/Ubuntu; apache RHEL)

cd /var/www/html/site

# Dizinler 755
find . -type d -exec chmod 755 {} +

# Dosyalar 644
find . -type f -exec chmod 644 {} +

# wp-config.php hassas — sirla parolasi var
chmod 440 wp-config.php       # owner okur, grup okur, others hicbir sey
# veya daha siki:
chmod 400 wp-config.php       # sadece owner okur

# .htaccess okunabilir 644 (Apache okuyacak)
chmod 644 .htaccess

# wp-content/uploads ozel: PHP yazacak
chown -R deployuser:www-data wp-content/uploads
chmod -R 755 wp-content/uploads
# Veya group write ile:
chmod -R 775 wp-content/uploads
# (SGID + 2775 daha temiz: yeni dosya otomatik www-data grup)
chmod 2775 wp-content/uploads

Nginx + PHP-FPM

PHP-FPM kendi pool user'i ile koşar (örn. www-data). Dosyalar deploy user (alperen) sahibi, grup PHP-FPM kullanıcısı:

chown -R alperen:www-data /var/www/site
find /var/www/site -type d -exec chmod 750 {} +
find /var/www/site -type f -exec chmod 640 {} +
chmod 400 /var/www/site/.env                  # daha siki — sadece okuma

Nginx static dosyaları doğrudan okur (worker process); PHP-FPM PHP'leri çalıştırır. Her ikisi de www-data grubunda olduğu için 640 dosya / 750 dizin yeterli.

mu-plugins, themes, plugins

chown -R deployuser:www-data wp-content/{plugins,themes,mu-plugins}
find wp-content/{plugins,themes,mu-plugins} -type d -exec chmod 755 {} +
find wp-content/{plugins,themes,mu-plugins} -type f -exec chmod 644 {} +

Plugin / theme güncellemeleri için web sunucu yazabilmeli mi sorusu mimari karara dönüşür:

• A) Sıkı (önerilen): WordPress otomatik güncelleme kapalı; deploy yapan kullanıcı manuel komut ile günceller. Web sunucu sadece okur. Daha güvenli.
• B) Esnek: WordPress otomatik güncelleme açık; web sunucu wp-content/plugins, wp-content/themes dizinlerine yazabilmeli — bunlar için 775 / SGID kullanılır. Saldırgan PHP RCE alırsa plugin enjekte edebilir riski var.

Buyukweb cPanel paketlerinde A modeli + ImunifyAV taraması standart yaklaşım; uzun vadeli güvenlik için tavsiye.

wp-config.php — En Hassas Dosya

wp-config.php veritabanı parolası, AUTH_KEY, secure salt'ları içerir. Mutlaka kısıtlı izin:

chmod 440 wp-config.php
# veya tam sertlestirilmis:
chmod 400 wp-config.php

cPanel altında bazen Apache'nin wp-config'i okuyabilmesi için 440 mantıklı (grup www-data). VDS'te eğer PHP-FPM kendi user'i ile koşuyor ve dosya o user'in sahibinde ise 400 yeterli (PHP-FPM zaten owner).

wp-config.php'yi web root'tan bir dizin yukarı taşımak (/var/www/html'nin üstüne) ek bir güvenlik önlemidir; WordPress otomatik üst dizini kontrol eder.

cPanel + CageFS Bağlamı (Buyukweb cPanel Paketleri)

Buyukweb cPanel paketlerinde CloudLinux + CageFS + LVE standart gelir. Bunların izin sistemine etkisi:

CageFS — Per-User Virtual Filesystem

Her cPanel kullanıcısı chroot-benzeri kendi sanal filesystem'i içinde yaşar. /usr, /bin, /etc dizinleri kullanıcıya filtrelenmiş görünür: sadece izin verilen binary'ler (whitelist) ve config dosyaları erişilebilir. Yan etkiler:

• find / -perm -4000 kullanıcı içinde çok kısıtlı sonuç döner — sistem SUID dosyalarının çoğu kullanıcıya görünmez.
• ps aux sadece kullanıcının kendi process'lerini gösterir; başka kiracıların process'leri gizlenmiş.
• /tmp per-user — /tmp/buyukweb_session_* dosyaları kullanıcı arasında karışmaz.

LVE — Linux Lightweight Containers

Her kullanıcı bir LVE konteyneri içinde koşar; CPU, RAM, I/O ve inode sayısı sınırlanır. Per-LVE disk + inode kotaları yanlış izin yapılandırmasının komşulara zarar vermesini engeller. Bir paylaşımlı sunucuda chmod 777 yapan bir kullanıcı bile diğer kiracıları doğrudan etkileyemez.

cPanel FileManager — İzin Numerik UI

cPanel FileManager üzerinden dosya seçip "Change Permissions" tıkladığınızda octal değer girilebilir veya checkbox ile rwx işaretlenir. UI sayısal değeri otomatik hesaplar (örn. 755 ↔ owner read/write/execute, group read/execute, other read/execute). Üretim için klasör 755, dosya 644, wp-config 440.

cPanel SSH ile chmod / chown

Buyukweb cPanel paketlerinde SSH erişimi standarttır. SSH ile bağlanıp chmod / chown direkt çalıştırabilirsiniz; ancak chown ile başka kullanıcıya geçemezsiniz — CageFS sınırı içinde sadece kendi UID'iniz erişilebilir, root erişim yok.

Yaygın İzin Hataları ve Çözümleri

1. "Permission denied" — chmod'dan Önce chown Kontrol

Klasik tuzak: dosyaya chmod 644 veriyorsunuz ama yine okuyamıyorsunuz. Sebep: dosya sizin değil. Web sunucusu www-data user'i ile koşar, dosya sahibi alperen, mod 600 (rw-------). Apache okuyamaz.

Çözüm: önce ownership:

chown alperen:www-data file.php
chmod 640 file.php             # owner rw, grup r (Apache okur)

2. WordPress "Upload failed" — uploads Dizini

Hata: "Unable to create directory wp-content/uploads/2026/05. Is its parent directory writable by the server?"

Sebep: wp-content/uploads dizini PHP-FPM/Apache kullanıcısı tarafından yazılabilir değil.

Çözüm:

chown -R alperen:www-data wp-content/uploads
chmod -R 775 wp-content/uploads
chmod 2775 wp-content/uploads     # SGID — yeni dosya/dizin otomatik www-data grup

3. Cron Çalışmıyor — Execute Biti Eksik

crontab -l
# 0 3 * * * /home/alperen/backup.sh

# Calistirilamiyor: -bash: /home/alperen/backup.sh: Permission denied
ls -l backup.sh
# -rw-r--r-- (644 — x yok)

chmod +x backup.sh                # u+g+o x ekle
# veya sadece owner:
chmod u+x backup.sh

cron sessizce başarısız olur; ilk denetim grep CRON /var/log/syslog veya journalctl -u cron çıktısına bakmak.

4. SSH Private Key Mod Yanlış

ssh -i ~/.ssh/id_ed25519 user@host
# WARNING: UNPROTECTED PRIVATE KEY FILE!
# Permissions 0644 for '/home/alperen/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh
chmod 644 ~/.ssh/id_ed25519.pub   # public key 644 OK
chmod 644 ~/.ssh/authorized_keys  # 644 veya 600 — ikisi de calisir

SSH client 0644 private key'i kabul etmez — başka kullanıcılar okuyabileceği için. 600 zorunlu.

5. chmod -R 777 Üretim Krizi

Birisi panik halinde chmod -R 777 /var/www yaptı. Bütün dosyalar dünyaya yazılabilir oldu. Recovery:

cd /var/www
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
find . -name "wp-config.php" -exec chmod 440 {} +
find . -name ".env" -exec chmod 400 {} +
find . -type f -name "*.sh" -exec chmod 755 {} +
chown -R deployuser:www-data .

Akabinde dosya bütünlük denetimi (AIDE) ve site malware taraması (ImunifyAV / Maldet) yapın — kötü adam zaten exploit etmiş olabilir.

6. Sahipsiz Dosyalar

Kullanıcı silindi ama dosyaları kaldı:

find / -nouser 2>/dev/null
# /var/log/old_user_logs/*

# Yeni sahibe devret:
chown -R deployuser:devs /var/log/old_user_logs

Audit Araçları

find tabanlı denetim

# SUID dosya inventory (haftalik snapshot tut)
find / -perm -4000 -type f -ls 2>/dev/null > /root/audit/suid-$(date +%F).txt

# Karsilastir:
diff /root/audit/suid-2026-05-04.txt /root/audit/suid-2026-05-11.txt

# Beklenmedik SUID = soru isareti

Lynis

Lynis sistem genel sertleştirme audit aracı. İzinleri içerir:

lynis audit system
# Includes: file permissions, SUID/SGID enumeration, world-writable files

CIS Benchmark uyum testleri için Lynis Buyukweb VDS'te güçlü bir başlangıç. Detay: Lynis ve AIDE Audit Rehberi.

AIDE (Advanced Intrusion Detection Environment)

Dosya bütünlük denetimi. İlk kurulum sonrası aide --init baseline alır; sonra periyodik aide --check ile değişimi raporlar — izin değişikliği, sahip değişikliği, içerik değişikliği yakalar.

getfacl recursive

getfacl -R /srv/shared > /root/audit/acl-$(date +%F).txt

ACL inventory; saldırgan ekstra ACL eklemiş mi kontrol için.

SELinux ve AppArmor — DAC Üstü MAC (Kısa)

DAC ("dosya sahibi izin verir") yetmediği durumlarda MAC ("sistem policy izin verir") devreye girer:

• SELinux — RHEL / AlmaLinux / Rocky / Fedora varsayılanı. Dosya label (unconfined_t, httpd_sys_content_t, vb.) + process domain + policy matrisi. ls -Z ile label görüntülenir. semanage fcontext ile label set, restorecon ile uygulanır.
• AppArmor — Ubuntu / Debian / SUSE varsayılanı. Path tabanlı (label değil). /etc/apparmor.d/ altında profile dosyaları; aa-status ile aktif profile'lar görülür.

DAC + MAC birlikte: Apache www-data user'i bir wp-config.php dosyasını DAC izin matrisinden geçer (mod 640 + grup www-data), ama SELinux'ta httpd_sys_content_t label olmadan okuyamaz. Bu nedenle SELinux aktif sunucuda restorecon koşmak zorunda kalır.

Detay: Linux CIS Benchmark Sertleştirme rehberinde SELinux / AppArmor bölümü daha geniş işlenir.

Buyukweb VDS vs cPanel — İzin Yönetimi Karşılaştırma

Yönü	cPanel Paketler (₺350-2.000/yıl)	VDS E5-V4
Root erişim	Yok (Buyukweb tarafı)	Tam
chmod/chown serbestliği	Kullanıcı home içinde tam	Sistem geneli tam
SUID dosya görünürlüğü	CageFS ile filtrelenmiş	Tam görünür
ACL desteği	Var (kullanıcı home'unda)	Var (tüm filesystem)
Capabilities	Kullanıcı setleyemez	Tam kontrol
FileManager UI	Var (numerik + checkbox)	Yok (SSH veya sftp client)
CageFS izolasyon	Var	Kullanıcıya bağlı (Docker / namespace / chroot)
umask varsayılan	022	Distro varsayılanı (Ubuntu/Debian 022, RHEL 022)
SELinux / AppArmor	Buyukweb yönetir	Siz yönetirsiniz

Sık Sorulan Sorular (SSS)

"chmod 777 niçin kötü?"

777 (rwxrwxrwx) demek "her kullanıcı her şey yapabilir". Üretim sunucusunda bu:

1. Başka bir kiracı (paylaşımlı hosting) veya kompromize başka servis (VDS) dosyanıza yazabilir → PHP backdoor enjekte edilir.
2. Bir başka kullanıcı dosyayı silebilir (sticky bit yoksa) → web siteniz kaybolur.
3. Audit / uyumluluk reddedilir — PCI-DSS, CIS Benchmark 777 modu bulgu olarak işaretler.
4. WordPress / Apache aslında 777 istemez — 755/644 yeterlidir. 777 sadece "bilmem nasıl çözerim" çaresizliğinden gelir.

Doğru çözüm: ownership doğru chown ile, izin minimum gerekli (genelde dizin 755, dosya 644, hassas 600).

"wp-config.php hangi izin olmalı?"

440 (owner ve grup okur, others yok) veya 400 (sadece owner okur). Eğer Apache www-data grubunda ise 440; eğer PHP-FPM owner'sa 400 yeterli. wp-config.php'yi web root'tan bir dizin yukarı taşımak (örn. /var/www/wp-config.php ve siteyi /var/www/html/ altında tutmak) bonus güvenlik.

"chown ve chmod hangi sırada çalıştırılır?"

İkisi de bağımsız ama mantıklı sıra: önce chown (kim sahibi), sonra chmod (sahibin hakkı ne). Bir deploy script'inde:

# 1. Sahiplik
chown -R deployuser:www-data /var/www/site

# 2. Dizin izinleri
find /var/www/site -type d -exec chmod 755 {} +

# 3. Dosya izinleri
find /var/www/site -type f -exec chmod 644 {} +

# 4. Hassas
chmod 440 /var/www/site/wp-config.php
chmod 400 /var/www/site/.env

"SUID ve SGID arasındaki fark?"

SUID (set-user-id) çalıştırılan dosyanın owner UID'i ile koşmasını sağlar. Örnek: passwd SUID root, sıradan kullanıcı çalıştırınca root UID ile koşar.

SGID (set-group-id) iki anlam: (1) dosyada → group GID ile koşar (wall tty grubu); (2) dizinde → o dizinde oluşturulan yeni dosya/dizin dizinin grubunu alır (paylaşımlı dizinler için altın).

"POSIX ACL klasik mode'a göre ne ek getirir?"

Klasik mode'da sadece owner / group / other üç entity vardır. ACL ile named user (örn. "Alice yazabilsin") ve named group (örn. "auditors okusun") ekleyebilirsiniz; ayrıca dizin default ACL ile yeni dosyaların otomatik miras alacağı izni belirleyebilirsiniz. Klasik mode + SGID + grup üyeliği basit senaryoları çözer; karmaşık paylaşım (5+ farklı izin grubu) için ACL gerekir.

"Capabilities mı SUID mi tercih edeyim?"

Modern Linux'ta capabilities tercih edin. SUID dosya sahibinin tam yetkisini ödünç verir; capability ise sadece gereken yetkiyi verir. Örnek: web server'a CAP_NET_BIND_SERVICE verirseniz port 80 bind eder ama /etc/shadow okuyamaz. SUID root verseydiniz her şeyi yapardı. Saldırı yüzeyini ciddi şekilde daraltır.

"umask değerini sistem genelinde nasıl değiştiririm?"

Modern dağıtımda PAM ile login zamanı uygulanır:

• Debian / Ubuntu: /etc/login.defs içinde UMASK 022 ve /etc/pam.d/common-session içinde session optional pam_umask.so.
• RHEL / AlmaLinux / Rocky: /etc/login.defs içinde UMASK 022.
• systemd service: UMask=0027 direktifi [Service] bloğuna ekleyin.
• Per-shell: ~/.bashrc, ~/.profile veya /etc/profile.d/umask.sh ile umask 027 yazın.

Değişiklik sonrası yeni shell oturumu açın — mevcut process'lere geçmez.

"chmod -R 644 dizine de uygulanır, sorun olur mu?"

Evet, olur. Dizin için 644 (rw-r--r--) execute biti yok = dizine girilemez. cd /var/www çalışmaz, dosyalara erişilemez. Doğru yaklaşım dizinlerle dosyaları ayırmak (find -type d / -type f) ya da chmod -R u=rwX,g=rX,o=rX (capital X) ile dizinleri ve halihazırda x olan dosyaları akıllıca yönetmek.

"ACL eklenmiş bir dosyada chmod ne yapar?"

chmod klasik group bitlerini değiştirir; ACL aktifse mask'i değiştirir. Bu sürpriz olabilir: getfacl çıktısında mask::r-- görünür ama user:alice:rwx etiketinin yanında # effective:r-- (mask ile sınırlanmış) yazar. Bu nedenle ACL aktif dosyada chmod öncesi mevcut ACL'i görmek için getfacl koşmak doğru pratiktir.

"Buyukweb cPanel'de root erişimim olmadan SUID dosya oluşturabilir miyim?"

Hayır. CageFS izolasyonu ile SUID dosya oluşturma kullanıcıya kapatılır; binary'yi siz yüklemiş olsanız bile mount option nosuid ile çalışır — SUID biti var ama kernel ignore eder. Tam SUID/SGID/setcap kontrolü için VDS alın; root erişiminiz olur.

Sonuç

Linux izin sistemi 1970'lerden gelen sade ama çok katmanlı bir tasarımdır. Üretim ortamı için pratik özet:

1. Dizin 755, dosya 644 standart başlangıç.
2. Hassas dosya 600 / 400 / 440 — SSH özel anahtar, wp-config.php, .env.
3. chown önce, chmod sonra — sahiplik doğru olsun, sonra mod ayarlansın.
4. SUID/SGID dosyaları periyodik audit — beklenmedik SUID rootkit göstergesi.
5. Paylaşımlı dizin için SGID + 2775 — yeni dosyalar otomatik grup miras.
6. POSIX ACL klasik mode yetmiyorsa — named user / named group.
7. Capabilities SUID yerine modern alternatif — ince taneli yetki.
8. umask 022 klasik, 027 veya 077 sertleştirme.
9. Asla chmod -R 777 üretimde — güvenlik açığı resmi davet.
10. SELinux / AppArmor DAC üzerine MAC katmanı — CIS Benchmark sertleştirme.

Buyukweb cPanel paketlerinde CageFS + LVE per-user izolasyon size hazır gelir; izin yönetimi kullanıcı home dizini ile sınırlıdır. VDS'lerde tam root erişim var, izin politikası sizin elinizde. Bursa Tier 3 veri merkezinden 17+ yıllık hosting deneyimi ile sunulan altyapımız üzerinde, izin yapılandırma sorularınız için 0850 302 60 70 numaralı destek hattımıza yazabilirsiniz.

---

İlgili Büyükweb Hizmetleri

• cPanel Web Hosting — CageFS + LVE per-user izolasyon, paylaşımlı paket
• VDS Sunucu (E5-V4) — Root erişim, tam DAC + MAC kontrolü
• Linux Kullanıcı ve Grup Yönetimi — useradd, sudo, PAM ile hesap yönetimi
• Linux CIS Benchmark Sertleştirme — DAC + SELinux + AppArmor güvenlik bütünü
• Lynis ve AIDE Audit Rehberi — Dosya bütünlük denetimi
• SSH Anahtar Kimlik Doğrulama — ~/.ssh ve key dosya izinleri

Linux dosya izin politikası, ACL planlaması veya CageFS / LVE detayları için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezinden 17+ yıldır web hosting, VDS ve dedicated sunucu hizmeti sunuyoruz.