ACL ile Gelişmiş Dosya Yetkilendirmesi

yazar

Standart Unix izin sistemi çoğu zaman yeterli gelir, ama bazı senaryolarda kendinizi çaresiz hissedersiniz. Örneğin bir dizine belirli bir kullanıcıya okuma izni vermek istiyorsunuz, ama o kullanıcı ilgili gruba dahil değil ve grubu değiştirmek de başka şeyleri bozacak. İşte tam bu noktada ACL (Access Control List) devreye girer ve hayatınızı kurtarır.

ACL Nedir ve Neden Lazım?

Geleneksel Unix izin modeli üç katmandan oluşur: dosya sahibi, grup ve diğerleri. Her katman için okuma, yazma ve çalıştırma izinleri tanımlanır. Bu model on yıllardır işe yaramıştır, ama modern sistemlerde yetersiz kalmaya başlamıştır.

Şöyle düşünün: Bir web sunucusunda proje dosyaları var. Geliştirici ahmet bu dosyaları düzenleyebilmeli, nginx kullanıcısı okuyabilmeli, deploy scripti ise hem okuyup hem yazabilmeli. Geleneksel modelde bunu temiz bir şekilde çözmek neredeyse imkânsız. Ya herkesi aynı gruba koyuyorsunuz ya da dosya izinlerini 777 yapıp sonra pişman oluyorsunuz.

ACL ile her kullanıcı veya grup için ayrı ayrı izin tanımlayabilirsiniz. Dosyanın sahibini, grubunu ya da diğer kullanıcıları etkileyen standart izinlere dokunmadan ek izinler ekleyebilirsiniz. Bu esneklik, özellikle paylaşımlı sunucularda ve kurumsal ortamlarda çok kritik hale gelir.

ACL Kurulumu ve Hazırlık

Çoğu modern Linux dağıtımında ACL araçları zaten kurulu gelir. Ama emin olmak için kontrol edin:

# Debian/Ubuntu
sudo apt install acl

# RHEL/CentOS/Rocky Linux
sudo dnf install acl

# Arch Linux
sudo pacman -S acl

ACL’nin çalışması için dosya sisteminin ACL desteğiyle mount edilmiş olması gerekir. Ext4, XFS ve Btrfs dosya sistemleri ACL’yi varsayılan olarak destekler. Durumu kontrol etmek için:

# Mount seçeneklerini kontrol et
mount | grep "^/dev"

# Veya daha detaylı
tune2fs -l /dev/sda1 | grep "Default mount options"

Eski sistemlerde /etc/fstab dosyasına acl parametresi eklemek gerekiyordu. Örneğin:

/dev/sda1  /  ext4  defaults,acl  0 1

Ama Linux çekirdeği 2.6.x’ten itibaren ext4 ve XFS için ACL varsayılan olarak aktif gelir, bu yüzden büyük ihtimalle ek bir şey yapmanıza gerek yoktur.

Temel ACL Komutları: getfacl ve setfacl

ACL dünyasında iki temel komutunuz var: getfacl ve setfacl. Biri okur, diğeri yazar. Önce mevcut durumu görmekle başlayalım:

# Bir dosya veya dizinin mevcut ACL'sini görüntüle
getfacl /var/www/proje

# Örnek çıktı:
# file: var/www/proje
# owner: www-data
# group: www-data
# user::rwx
# group::r-x
# other::r-x

Bu çıktı şu an standart Unix izinlerinin ACL formatında gösterilmiş hali. Herhangi bir ek ACL girişi yok. Şimdi setfacl ile izin eklemeye başlayalım:

# Kullanıcıya izin ver
# setfacl -m u:kullanici:izinler dosya
setfacl -m u:ahmet:rwx /var/www/proje

# Gruba izin ver
# setfacl -m g:grup:izinler dosya
setfacl -m g:developers:rx /var/www/proje

# Sonucu kontrol et
getfacl /var/www/proje

setfacl parametreleri:

  • -m: Mevcut ACL’yi değiştir (modify)
  • -x: Belirli bir ACL girişini sil (remove)
  • -b: Tüm ACL girişlerini sil
  • -R: Alt dizinlere de uygula (recursive)
  • -d: Varsayılan ACL tanımla (default)
  • –set: Tüm ACL’yi sıfırdan tanımla
  • -k: Sadece varsayılan ACL’leri sil

Gerçek Senaryo 1: Web Sunucusu Dizin Yönetimi

Bir ajans ortamında çalıştığınızı düşünün. Müşterilerin web siteleri /var/www/ altında tutuluyor. Her müşteri için ayrı bir klasör var ve şu gereksinimleriniz var:

  • www-data kullanıcısı tüm siteleri okuyabilmeli
  • Her müşterinin geliştiricisi sadece kendi sitesini düzenleyebilmeli
  • DevOps ekibi tüm sitelere erişebilmeli
  • Güvenlik denetçisi sadece okuma yapabilmeli
# Müşteri dizinini oluştur
sudo mkdir -p /var/www/musteri-a
sudo chown www-data:www-data /var/www/musteri-a

# Müşterinin geliştiricisine tam izin ver
sudo setfacl -m u:gelistirici-a:rwx /var/www/musteri-a

# DevOps grubuna tam izin ver
sudo setfacl -m g:devops:rwx /var/www/musteri-a

# Güvenlik denetçisine sadece okuma izni ver
sudo setfacl -m u:denetci:r-x /var/www/musteri-a

# Sonucu kontrol et
getfacl /var/www/musteri-a

Ama burada bir sorun var: Yeni oluşturulan dosyalar bu ACL kurallarını miras almaz. Bunun için default ACL kullanmanız gerekir.

# Dizine default ACL ekle
sudo setfacl -d -m u:gelistirici-a:rwx /var/www/musteri-a
sudo setfacl -d -m g:devops:rwx /var/www/musteri-a
sudo setfacl -d -m u:denetci:r-x /var/www/musteri-a
sudo setfacl -d -m u::rw /var/www/musteri-a
sudo setfacl -d -m g::r /var/www/musteri-a
sudo setfacl -d -m o::- /var/www/musteri-a

# Hem normal hem default ACL'yi tek komutla görmek için
getfacl /var/www/musteri-a

Default ACL tanımladıktan sonra o dizin altında oluşturulan her yeni dosya ve klasör otomatik olarak bu izinleri alır. Bu, özellikle uygulama tarafından oluşturulan dosyalar için kritik bir özelliktir.

ACL Mask Kavramı

getfacl çıktısında mask satırını görürsünüz ve bu satır çoğu kişiyi şaşırtır. Mask, ACL’deki kullanıcılar (dosya sahibi hariç) ve gruplar için maksimum izin sınırını belirler.

# Bir örnek görelim
getfacl /var/www/musteri-a

# Çıktıda şunu görürsünüz:
# user::rwx
# user:ahmet:rwx        #effective: rwx
# group::r-x            #effective: r-x
# group:devops:rwx      #effective: rwx
# mask::rwx
# other::r-x

Mask’ı değiştirdiğinizde ne olur?

# Mask'ı sadece okuma olarak ayarla
setfacl -m mask::r-x /var/www/musteri-a

# Şimdi getfacl'e bakın
getfacl /var/www/musteri-a

# Çıktı:
# user::rwx
# user:ahmet:rwx        #effective: r-x   <- Etkin izin düştü!
# group::r-x            #effective: r-x
# group:devops:rwx      #effective: r-x   <- Etkin izin düştü!
# mask::r-x
# other::r-x

Mask sayesinde tek bir yerden tüm ek izinleri kısıtlayabilirsiniz. chmod komutu kullandığınızda da mask otomatik olarak güncellenir, bu yüzden ACL’li dosyalarda chmod kullanırken dikkatli olun.

Gerçek Senaryo 2: Paylaşımlı Geliştirme Ortamı

Ekibinizde farklı roller var: senior geliştiriciler, junior geliştiriciler ve test mühendisleri. Kaynak kod deposu /opt/proje altında tutuluyor.

Gereksinimler:

  • Senior geliştiriciler her şeyi okuyup yazabilmeli
  • Junior geliştiriciler sadece src/ klasörüne yazabilmeli, diğerlerini okuyabilmeli
  • Test mühendisleri sadece tests/ klasörüne yazabilmeli
  • Konfigürasyon dosyaları sadece senior geliştiriciler tarafından değiştirilebilmeli
# Dizin yapısını oluştur
sudo mkdir -p /opt/proje/{src,tests,config,docs}

# Temel sahipliği ayarla
sudo chown -R deploy:developers /opt/proje
sudo chmod -R 750 /opt/proje

# Senior geliştiricilere tam izin
sudo setfacl -Rm g:senior-dev:rwx /opt/proje
sudo setfacl -Rdm g:senior-dev:rwx /opt/proje

# Junior geliştiricilere ana dizini okuma, src'yi yazma
sudo setfacl -m g:junior-dev:r-x /opt/proje
sudo setfacl -Rm g:junior-dev:rwx /opt/proje/src
sudo setfacl -Rm g:junior-dev:r-x /opt/proje/tests
sudo setfacl -Rm g:junior-dev:r-x /opt/proje/docs
sudo setfacl -Rm g:junior-dev:--- /opt/proje/config

# Test mühendislerine tests dizinini yazma
sudo setfacl -m g:qa-team:r-x /opt/proje
sudo setfacl -Rm g:qa-team:rwx /opt/proje/tests
sudo setfacl -Rm g:qa-team:r-x /opt/proje/src
sudo setfacl -Rm g:qa-team:r-x /opt/proje/docs

# Default ACL'leri de ayarla
sudo setfacl -dm g:senior-dev:rwx /opt/proje/src
sudo setfacl -dm g:junior-dev:rwx /opt/proje/src
sudo setfacl -dm g:qa-team:rwx /opt/proje/tests

ACL’leri Yedekleme ve Geri Yükleme

Sunucu taşıma ya da yedekleme senaryolarında ACL bilgilerini de saklamanız gerekir. rsync varsayılan olarak ACL’leri taşımaz, tar da aynı şekilde. Bunun için özel yaklaşımlar kullanmalısınız.

# Bir dizinin tüm ACL'lerini dosyaya yedekle
getfacl -R /var/www > /backup/www_acl_backup.txt

# Yedekten geri yükle
setfacl --restore=/backup/www_acl_backup.txt

# rsync ile ACL'leri de taşı
rsync -avX /kaynak/ /hedef/

# tar ile ACL'leri de sakla (GNU tar)
tar --acls -czf yedek.tar.gz /var/www/

# tar ile geri yükle
tar --acls -xzf yedek.tar.gz

-X parametresi rsync için extended attribute’ları taşır ve ACL’ler de bu kapsamda değerlendirilir. Bunu unutursanız, büyük bir taşıma işleminden sonra tüm ACL yapılandırmanızı yeniden yapmanız gerekebilir. Söyleyen söyledi.

Gerçek Senaryo 3: Log Dosyalarına Kontrollü Erişim

Güvenlik ekibiniz belirli log dosyalarını izlemek istiyor ama root erişimi vermeniz mümkün değil. Aynı zamanda geliştirme ekibi uygulama loglarını görebilmeli ama sistem loglarına erişememeliydi.

# Sistem logları için sadece güvenlik ekibine okuma izni
sudo setfacl -m g:security-team:r-- /var/log/auth.log
sudo setfacl -m g:security-team:r-- /var/log/syslog
sudo setfacl -m g:security-team:r-- /var/log/kern.log

# Uygulama logları için geliştirme ekibine izin
sudo setfacl -Rm g:developers:r-x /var/log/uygulama/
sudo setfacl -Rdm g:developers:r-- /var/log/uygulama/

# Log rotasyonu sonrası ACL'lerin kaybolmaması için
# logrotate.d konfigürasyonuna script ekle
# /etc/logrotate.d/uygulama
cat << 'EOF' | sudo tee /etc/logrotate.d/uygulama
/var/log/uygulama/*.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
    postrotate
        setfacl -Rm g:developers:r-x /var/log/uygulama/
        setfacl -Rdm g:developers:r-- /var/log/uygulama/
    endscript
}
EOF

Log rotasyonu önemli bir detay. logrotate yeni log dosyaları oluşturduğunda ACL’ler sıfırlanabilir. Postrotate script ile bunu otomatik olarak yeniden uyguluyoruz.

ACL ve Geleneksel İzinlerin Birlikte Çalışması

ACL ve standart Unix izinleri birlikte çalışır. Bir kullanıcı bir dosyaya erişmek istediğinde sistem şu sırayla kontrol eder:

  • Kullanıcı dosyanın sahibi mi? Sahip izinleri uygulanır.
  • Kullanıcı için özel bir ACL girişi var mı? O izin ve mask uygulanır.
  • Kullanıcının grubu için ACL girişi var mı? O izin ve mask uygulanır.
  • Hiçbiri yoksa other izinleri uygulanır.

Bu hiyerarşiyi anlamak çok önemli. Özellikle şunu bilin: Reddetme (deny) kuralı yoktur. ACL sadece izin verir, yasaklama mekanizması yoktur. Eğer bir kullanıcı birden fazla grup üzerinden erişim hakkı kazanıyorsa, en geniş izin geçerli olur.

# Pratik test: Bir kullanıcının bir dosyaya erişip erişemeyeceğini test et
# (sudo ile başka kullanıcı olarak dene)
sudo -u ahmet cat /var/www/musteri-a/index.html

# Veya su ile geç
su - ahmet -c "ls -la /var/www/musteri-a/"

ACL’leri Toplu Yönetmek için Script

Büyük sistemlerde ACL’leri elle yönetmek yorucu hale gelir. Basit bir bash scripti ile bu işi otomatize edebilirsiniz:

#!/bin/bash
# acl-setup.sh - Proje ACL'lerini toplu ayarla

set -euo pipefail

PROJE_DIZIN="/var/www/projeler"
LOG_FILE="/var/log/acl-setup.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

acl_uygula() {
    local dizin="$1"
    local kullanici_ya_grup="$2"
    local izin="$3"
    local tip="$4"  # u veya g

    if [ ! -d "$dizin" ]; then
        log "HATA: $dizin bulunamadi"
        return 1
    fi

    # Normal ACL
    setfacl -Rm "${tip}:${kullanici_ya_grup}:${izin}" "$dizin"
    # Default ACL
    setfacl -Rdm "${tip}:${kullanici_ya_grup}:${izin}" "$dizin"

    log "ACL uygulandı: $dizin -> $tip:$kullanici_ya_grup:$izin"
}

# Mevcut ACL'leri yedekle
log "ACL yedeği alınıyor..."
getfacl -R "$PROJE_DIZIN" > "/backup/acl_$(date +%Y%m%d_%H%M%S).txt"

# ACL'leri uygula
for proje in "$PROJE_DIZIN"/*/; do
    proje_adi=$(basename "$proje")
    log "İşleniyor: $proje_adi"

    acl_uygula "$proje" "devops" "rwx" "g"
    acl_uygula "$proje" "denetci" "r-x" "g"
    acl_uygula "$proje/logs" "developers" "r-x" "g"
done

log "ACL kurulumu tamamlandı"

Bu scripti cron ile çalıştırabilir ya da Ansible playbook’larınıza entegre edebilirsiniz.

Sorun Giderme

ACL ile çalışırken karşılaşabileceğiniz yaygın sorunlar ve çözümleri:

Sorun: Operation not supported hatası

# Dosya sistemi ACL desteklemiyor mu kontrol et
tune2fs -l /dev/sda1 | grep "Default mount options"

# ACL desteğini aktif et (eski sistemler için)
sudo mount -o remount,acl /

Sorun: ACL ayarladım ama kullanıcı hâlâ erişemiyor

# Mask değerini kontrol et
getfacl /dizin | grep mask

# Effective izinleri kontrol et (# işareti olan satırlar)
getfacl /dizin

# Kullanıcının gerçekten o grupta olup olmadığını kontrol et
groups kullanici_adi
id kullanici_adi

Sorun: Yeni oluşturulan dosyalar ACL almıyor

# Default ACL tanımlanmış mı kontrol et
getfacl /dizin | grep "^default:"

# Default ACL yoksa ekle
setfacl -d -m g:developers:rwx /dizin

Sorun: cp komutu ACL’leri kopyalamıyor

# --preserve=all ile kopyala
cp --preserve=all kaynak hedef

# Ya da -a parametresi kullan
cp -a kaynak hedef

Güvenlik Tavsiyeleri

ACL güçlü bir araç ama yanlış kullanıldığında güvenlik açığı yaratabilir.

  • En az yetki prensibini uygulayın. Her kullanıcıya ve gruba sadece işini yapması için gereken minimum izni verin.
  • ACL kurallarını düzenli olarak denetleyin. getfacl -R /kritik/dizin ile periyodik kontroller yapın.
  • other için asla yazma izni vermeyin. ACL eklerken other iznini de gözden geçirin.
  • ACL değişikliklerini loglayın. Yukarıdaki script örneğinde olduğu gibi değişiklik kayıtları tutun.
  • Default ACL’leri unutmayın. Normal ACL koyup default ACL koymamak, yeni oluşturulan dosyaların korumasız kalmasına yol açar.
  • Düzenli olarak ACL yedeklerini alın ve felaket kurtarma planınıza dahil edin.

Sonuç

ACL, Linux’taki geleneksel dosya izin modelinin sınırlarını ortadan kaldıran ve size gerçek anlamda granüler kontrol sağlayan bir araçtır. Özellikle paylaşımlı sunucularda, kurumsal ortamlarda ve kompleks erişim gereksinimlerinde hayat kurtarıcıdır.

getfacl ve setfacl komutlarını öğrenmek birkaç saatlik bir iş. Ama mask kavramını, default ACL’lerin önemini ve log rotasyonu gibi senaryolarda ACL’lerin nasıl davrandığını kavramak zaman alır. Bu yüzden test ortamınızda pratik yapmaktan çekinmeyin.

Sisteminizde yarın hemen uygulayabileceğiniz bir adım önereyim: En kritik dizinlerinizde getfacl -R /dizin çalıştırın ve mevcut durumu bir dosyaya kaydedin. Bu hem mevcut durumu anlamanızı sağlar hem de bir şeyler ters gittiğinde geri dönebileceğiniz bir referans noktası oluşturur. Sistem yönetimi her zaman “önce anla, sonra değiştir” prensibiyle yürür.

Yorum yapın