bindfs ile Dizinleri Farklı İzin ve Sahiplikle Yeniden Bağlama

Üretim ortamında klasör izinleriyle boğuşmak, sysadmin hayatının kaçınılmaz bir parçası. Özellikle birden fazla servisin aynı veri dizinine erişmesi gerektiğinde, ya da bir uygulamanın belirli bir kullanıcıyla çalışmasını istediğinizde işler karmaşıklaşıyor. İşte tam burada bindfs devreye giriyor ve hayatı ciddi anlamda kolaylaştırıyor.

bindfs, FUSE (Filesystem in Userspace) tabanlı bir araç. Bir dizini farklı bir konuma mount ediyor, ama asıl sihir şurada: mount ederken dosya sahipliğini ve izinlerini istediğiniz gibi yeniden tanımlayabiliyorsunuz. Orijinal dosyalar hiç değişmiyor, sadece o mount noktasından bakan kullanıcı farklı bir sahiplik ve izin görüyor. Gerçek veriye dokunan yok, sadece görünüm değişiyor.

bindfs Nedir ve Neden Kullanılır?

Klasik bind mount’tan (mount --bind) farkı şu: mount --bind dizini başka bir yere bağlar ama izinler ve sahiplik aynı kalır. bindfs ise bu katmanın üstüne izin dönüşümü ekliyor. Yani kaynak dizindeki root:root sahipliğindeki dosyaları, hedef mount noktasında www-data:www-data gibi gösterebiliyorsunuz.

Gerçek dünyada karşılaştığım tipik durumlar şunlar:

• Bir NAS veya paylaşımlı depolama alanını birden fazla kullanıcıya farklı izinlerle sunmak
• Docker container’larına host üzerindeki dizinleri farklı UID/GID ile bağlamak
• Bir web uygulamasının yüklemeler klasörüne hem web sunucusunun hem de bir backup servisinin erişmesi
• Bir geliştiriciye production verilerini read-only olarak göstermek
• Vagrant veya LXC ortamlarında sahiplik sorunlarını çözmek

Kurulum

Çoğu dağıtımda bindfs paket depolarında mevcut.

# Debian/Ubuntu
sudo apt-get install bindfs

# RHEL/CentOS/Fedora
sudo dnf install bindfs

# Arch Linux
sudo pacman -S bindfs

# macOS (FUSE gerektirir)
brew install bindfs

FUSE bağımlılığı otomatik çekilir ama bazı minimal kurulumlardan sonra fuse kernel modülünün yüklü olduğunu doğrulamak iyi fikir:

lsmod | grep fuse
# Çıktı yoksa:
sudo modprobe fuse

Temel Kullanım Sözdizimi

bindfs [seçenekler] kaynak_dizin hedef_dizin

En basit haliyle, bir dizini başka bir yere bağlamak:

bindfs /var/www/html /mnt/web-mirror

Bu komut /var/www/html içeriğini /mnt/web-mirror‘da da gösterir. Şimdi izinleri değiştirelim.

Sahiplik Dönüşümü

Kullanıcı ve Grup Eşlemesi

bindfs‘in en çok kullandığım özelliği sahiplik dönüşümü. Diyelim ki /data/uploads dizini root’a ait ama bunu www-data kullanıcısına aitmiş gibi göstermek istiyorsunuz:

sudo bindfs --map=root/www-data:@root/@www-data /data/uploads /mnt/web-uploads

Buradaki sözdizimini açıklayayım:

• –map=root/www-data: root kullanıcısını www-data olarak göster
• :@root/@www-data: root grubunu www-data grubu olarak göster

Şimdi /mnt/web-uploads üzerinden bakan biri tüm dosyaların www-data:www-data‘ya ait olduğunu görür. /data/uploads‘ta ise dosyalar hala root’a ait.

Birden fazla kullanıcı eşlemesi yapmak da mümkün, virgülle ayırarak:

sudo bindfs --map=1000/33:1001/33:@1000/@33 /data/shared /mnt/shared-mapped

UID/GID ile Çalışmak

Kullanıcı adı yerine doğrudan UID/GID kullanmak bazen daha güvenli, özellikle container ortamlarında isimler değişken olabiliyor:

sudo bindfs --map=1000/33 --map=@1000/@33 /home/deploy/uploads /mnt/nginx-uploads

Burada UID 1000 (genellikle ilk normal kullanıcı) dosyaları, UID 33 (Debian/Ubuntu’da www-data) olarak gösteriliyor.

İzin Manipülasyonu

Sahipliğin yanı sıra dosya izinlerini de override edebiliyorsunuz. Bu özellik özellikle read-only erişim senaryolarında çok işe yarıyor.

Tüm Dosyaları Read-Only Yapmak

sudo bindfs --perms=a-w /var/log/uygulama /mnt/log-readonly

--perms parametresi chmod sembolik gösterimini kullanıyor. a-w tüm kullanıcılardan yazma iznini kaldırıyor. Böylece bir geliştirici log dosyalarını okuyabiliyor ama değiştiremiyor.

Belirli İzin Maskeleri Uygulamak

sudo bindfs --perms=u=rD:g=rD:o= /data/confidential /mnt/readonly-share

Burada:

• u=rD: Sahip için okuma ve dizine girme izni (büyük D sadece dizinlere etki eder)
• g=rD: Grup için aynı
• o=: Diğerleri için hiçbir izin yok

Force İzinleri

Bazen kaynak dizindeki izinlere bakmaksızın belirli bir set uygulamak isteyebilirsiniz:

sudo bindfs --force-user=www-data --force-group=www-data 
  --perms=u=rwX:g=rX:o= 
  /data/media /mnt/media-served

Bu örnekte ne olursa olsun, hedef dizinden tüm dosyalar www-data sahibiyle ve o izinlerle görünüyor.

Gerçek Dünya Senaryoları

Senaryo 1: Web Sunucusu ve Backup Servisi

Bu sorunla geçen yıl bir e-ticaret altyapısında karşılaştım. Nginx, upload edilen ürün görsellerini /var/www/shop/uploads altında www-data kullanıcısıyla oluşturuyordu. Backup servisi ise farklı bir kullanıcıyla (backupuser) çalışıyordu ve bu dosyaları okumak için ya sudo vermek ya da başka bir çözüm bulmak gerekiyordu.

Sudo vermek istemiyorduk, grupla oynamak da riski artırıyordu. bindfs ile çözdük:

sudo bindfs --map=www-data/backupuser:@www-data/@backup 
  /var/www/shop/uploads 
  /mnt/backup/shop-uploads

Backup servisi /mnt/backup/shop-uploads üzerinden tüm dosyalara kendi kullanıcısıyla erişebildi. Hiçbir izin değişmedi, security posture bozulmadı.

Senaryo 2: Docker Volume Sahiplik Sorunu

Docker ile çalışanların klasik problemi: container içindeki UID ile host üzerindeki UID eşleşmiyor ve volume mount ettiğinizde ya okuyamıyorsunuz ya da yanlış kullanıcıyla yazıyorsunuz.

# Container nginx UID 101 ile çalışıyor ama host'ta bu dizin 1000'e ait
sudo bindfs --map=1000/101:@1000/@101 
  /home/ubuntu/nginx-data 
  /mnt/nginx-container-data

# Docker run sırasında bu mount noktasını kullan
docker run -v /mnt/nginx-container-data:/usr/share/nginx/html nginx

Artık container içinde UID 101 (nginx) dosyalara tam erişime sahip, host üzerinde ise dosyalar UID 1000’e ait görünmeye devam ediyor.

Senaryo 3: Geliştirici Ortamında Production Verisine Readonly Erişim

Bir geliştirici production log ve konfigürasyon dosyalarına bakmak istiyor ama tabii ki değiştirme iznine sahip olmamalı:

sudo bindfs 
  --map=root/developer:@root/@developers 
  --perms=a-w 
  /etc/nginx 
  /mnt/dev-nginx-readonly

Geliştirici /mnt/dev-nginx-readonly altında nginx konfigürasyonunu okuyabilir, developers grubuna ait olarak görür, ama yazma girişimi engellenir.

Senaryo 4: Samba ile Ev Dizini Paylaşımı

Farklı UID’lerle çalışan Windows ve Linux kullanıcıları arasında dosya paylaşımı yapıyorsanız:

sudo bindfs --map=1001/nobody:@1001/@nogroup 
  --create-for-user=1001 
  --create-for-group=1001 
  /home/shared-project 
  /mnt/samba-share

--create-for-user ve --create-for-group parametreleri, mount noktasında yeni oluşturulan dosyaların sahipliğini belirliyor. Bu sayede Samba üzerinden oluşturulan dosyalar bile doğru sahiple kaydediliyor.

Önemli Parametreler

Sık kullandığım parametrelerin özeti:

• –map=kullanici1/kullanici2: Kullanıcı eşlemesi yapar, kaynak dizindeki kullanici1’i hedefte kullanici2 olarak gösterir
• –force-user=kullanici: Tüm dosyaların sahibini override eder
• –force-group=grup: Tüm dosyaların grubunu override eder
• –perms=izinler: chmod sembolik notasyonuyla izin ayarlar
• –create-for-user=kullanici: Yeni oluşturulan dosyalara atanacak kullanıcıyı belirtir
• –create-for-group=grup: Yeni oluşturulan dosyalara atanacak grubu belirtir
• –read-only: Mount noktasını tamamen read-only yapar
• –no-allow-other: Sadece mount eden kullanıcının erişimine izinr verir
• –mirror=kullanici1:kullanici2: Belirli kullanıcılar için ayrı eşlemeler tanımlar
• –chmod-ignore: Kaynak dosyalardaki chmod değişikliklerini hedefte yansıtmaz
• –chown-ignore: Sahiplik değişikliklerini hedefte yoksayar
• -o allow_other: FUSE mount’u diğer kullanıcılara da açar (root olmayan kullanıcılar için mount yapıldığında gerekli)

fstab ile Kalıcı Bağlama

Her yeniden başlatmada komutu elle çalıştırmak istemezsiniz. /etc/fstab‘a ekleyebilirsiniz:

# /etc/fstab
bindfs#/data/uploads  /mnt/web-uploads  fuse  force-user=www-data,force-group=www-data,perms=u=rwX:g=rX:o=,_netdev  0  0

Veya biraz daha karmaşık bir eşleme için:

bindfs#/var/www/shop/uploads  /mnt/backup/shop-uploads  fuse  map=www-data/backupuser:@www-data/@backup,allow_other  0  0

Fstab’ı test etmek için:

sudo mount -a
# Hata yoksa mount oluştu, kontrol et:
mount | grep bindfs

Systemd Unit ile Yönetim

Fstab yerine systemd mount unit’i kullanmayı tercih ediyorum, daha fazla kontrol sağlıyor:

# /etc/systemd/system/mnt-web-uploads.mount
[Unit]
Description=bindfs mount for web uploads
After=local-fs.target

[Mount]
What=/data/uploads
Where=/mnt/web-uploads
Type=fuse.bindfs
Options=force-user=www-data,force-group=www-data,perms=u=rwX:g=rX:o=,allow_other

[Install]
WantedBy=multi-user.target

Etkinleştirmek ve başlatmak için:

sudo systemctl daemon-reload
sudo systemctl enable mnt-web-uploads.mount
sudo systemctl start mnt-web-uploads.mount
sudo systemctl status mnt-web-uploads.mount

Systemd mount unit’in adının, Where değerindeki path ile eşleşmesi gerekiyor. /mnt/web-uploads için dosya adı mnt-web-uploads.mount olmalı, slash’lar tire ile değiştiriliyor.

Mount’u Kaldırmak

# Normal kullanıcı kendi mount'unu kaldırabilir
fusermount -u /mnt/web-uploads

# Root olarak ya da lazy unmount için
sudo umount /mnt/web-uploads

# Meşgul mount noktası için
sudo umount -l /mnt/web-uploads

Dikkat Edilmesi Gereken Noktalar

Performance: FUSE tabanlı çözümler her zaman native filesystem’den biraz daha yavaş. Yüksek I/O yüklü ortamlarda bu farkı benchmark’larla ölçün. Genel web servisi için sorun olmaz ama yoğun veritabanı trafiği olan dizinlerde düşünün.

Güvenlik: allow_other seçeneğini dikkatli kullanın. Bu seçenek mount eden kullanıcı dışındakilerin de erişmesine izin veriyor. /etc/fuse.conf dosyasında user_allow_other direktifinin aktif olması gerekiyor bu seçenek için.

Recursive davranış: bindfs tüm alt dizinleri de kapsıyor, tek bir mount yeterli. Ama sembolik linkler konusunda dikkatli olun, semlink hedefleri mount’un dışındaysa onlara erişim için ayrı bir düzenleme gerekebilir.

Audit ve loglama: bindfs üzerinden yapılan işlemler kaynak dizin audit loglarına düşüyor mu, bunu test edin. FUSE katmanı bazı audit senaryolarını karmaşıklaştırabiliyor.

Hızlı Doğrulama

Kurulumun doğru çalıştığını test etmek için basit bir senaryo:

# Test dizini oluştur
mkdir -p /tmp/kaynak /tmp/hedef
echo "test dosyasi" > /tmp/kaynak/test.txt
chown root:root /tmp/kaynak/test.txt

# bindfs ile mount et
sudo bindfs --map=root/$(whoami):@root/@$(id -gn) /tmp/kaynak /tmp/hedef

# Doğrula
ls -la /tmp/hedef/
# Dosyanın artık mevcut kullanıcıya ait göründüğünü görmelisiniz

# Temizle
fusermount -u /tmp/hedef

Sonuç

bindfs, Linux üzerinde izin ve sahiplik yönetiminde gerçekten pratik bir araç. Özellikle mikroservis mimarilerinde, container ortamlarında ve çok kullanıcılı sistemlerde karşılaşılan sahiplik çakışmalarını, orijinal verilere dokunmadan çözüyor.

ACL’ler bazen işe yarıyor, bazen grupları yeniden düzenlemek bir çözüm sunuyor. Ama karmaşık UID eşlemesi senaryolarında veya birden fazla servisin aynı veriyi farklı kimliklerle görmesi gerektiğinde, bindfs diğer seçeneklere göre çok daha az risk ve efor gerektiriyor.

Production’da kurmadan önce staging ortamında test etmek, FUSE performans etkisini ölçmek ve systemd ya da fstab entegrasyonunu doğrulamak, sorunsuz bir dağıtım için kritik. Ama bir kez kurulup çalıştığında, ciddi bir bakım yükü olmadan uzun süre boyunca güvenilir şekilde çalışıyor.