NFS Nedir? NAS ve Sanallaştırmada Dosya Paylaşımı

NFS (Network File System), Unix ve Linux dünyasının dosya paylaşım protokolüdür ve 2049 numaralı portu kullanır. Bir sunucudaki dizini ağa açar, başka bir makine o dizini kendi dosya sisteminin içinde bir klasör gibi bağlar. Bağlandıktan sonra ortada uzak bir sunucu olduğu görünmez bile: uygulamalar /mnt/paylasim yolunu yerel bir klasör sanır.

Vestiyeri düşünün. Paltonuzu verirsiniz, karşılığında bir numara alırsınız. Görevli adınızı bilmez, hangi departmanda çalıştığınızı bilmez, sizi tanımak zorunda da değildir. Tek bildiği numaradır ve kural tektir: numarayı kim gösterirse paltoyu o alır. NFS’in kimlik anlayışı tam olarak budur ve bu makalenin anlattığı hemen her şey, bu tek cümlenin sonuçlarıdır.

Bu makale kurumsal network kurulumu hizmetimizin dosya paylaşım katmanına odaklanır; NFS’in içinde yer aldığı protokol zincirinin tamamını kurumsal ağ protokolleri rehberimizde ele alıyoruz. Aşağıdaki bütün ölçümler lab ortamımızdaki iki Ubuntu 24.04 sunucu arasında gerçekten çalıştırıldı: 192.168.1.15 sunucu, 192.168.1.25 istemci.

Bir izin sorununu çözmek için geldiyseniz ve protokolün mekaniğini zaten biliyorsanız, doğrudan kimlik modelinin anlatıldığı bölüme ya da teşhis bölümüne geçebilirsiniz.

NFS Nedir ve Nasıl Çalışır?

NFS, bir sunucudaki dizini ağ üzerinden başka makinelerin kullanımına açan istemci-sunucu protokolüdür. 1980’lerde Sun Microsystems’te doğdu, bugün Linux, BSD ve ticari Unix sistemlerinin ortak paylaşım dilidir. Ağa takılan storage kutularının, yani Network Attached Storage (NAS) cihazlarının neredeyse tamamı SMB’nin yanında NFS de konuşur.

Çalışma mantığı iki taraflı bir anlaşmadır ve iki fiilin adı protokolün sözlüğüne girmiştir:

• Export, sunucu tarafındaki karardır: “şu dizini, şu ağdaki makinelere, şu koşullarla açıyorum”.
• Mount, istemci tarafındaki karardır: “o dizini kendi ağacımın şu noktasına bağlıyorum”.

Sunucu tarafındaki export tanımı tek satırdır. Lab sunucumdaki /etc/exports dosyasına yazdığım satır şu:

/srv/paylasim  192.168.1.0/24(rw,sync,no_subtree_check)

Üç şey söylüyor: hangi dizin, kimlere, hangi koşullarla. rw yazma izni verir, sync yazma işlemini diske inmeden onaylamamayı söyler, no_subtree_check ise bir performans ve kararlılık tercihidir.

Ama bu satır yapılandırmanın tamamı değildir, yalnızca varsayılanlardan sapan kısmıdır. Yazmadığınız her seçenek sessizce devreye girer ve NFS’te varsayılanların ne olduğunu bilmemek, sonradan “ben böyle bir şey yazmamıştım” denen arızaların kaynağıdır. Sunucuya gerçekte ne dediğinizi exportfs -v ile görürsünüz:

sudo exportfs -ra
sudo exportfs -v

/srv/paylasim  192.168.1.0/24(sync,wdelay,hide,no_subtree_check,
                              sec=sys,rw,secure,root_squash,no_all_squash)

Üç satırlık bir tanım yazdım, sunucu bana dokuz seçenek geri okudu. Bunlardan ikisi bu makalenin geri kalanını belirliyor: sec=sys kimlik doğrulama yönteminin ne olduğunu, root_squash ise root kullanıcısına nasıl davranılacağını söylüyor. İkisine de sırası gelince döneceğiz.

İstemci Tarafı: Neyin Açık Olduğunu Görmek

İstemci, bağlanmadan önce sunucuda ne olduğunu sorabilir. showmount komutu tam olarak bunu yapar:

showmount -e 192.168.1.15

Export list for 192.168.1.15:
/srv/paylasim 192.168.1.0/24

Bu çıktı bir kolaylık gibi görünür ve teşhiste gerçekten öyledir. Ama aynı zamanda ilk güvenlik notudur: bu bilgiyi almak için hiçbir kimlik doğrulaması gerekmez. Ağda sunucuya ulaşabilen herkes, hangi dizinlerin hangi ağlara açıldığını öğrenebilir. NFS’in güvenilmeyen bir ağda işi olmamasının sebeplerinden biri budur.

Bağlanmak ise tek komut:

sudo mount -t nfs 192.168.1.15:/srv/paylasim /mnt/paylasim

Bağlandıktan sonra mount çıktısında hangi anlaşmanın kurulduğu yazar:

192.168.1.15:/srv/paylasim on /mnt/paylasim type nfs4
  (rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,
   proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.25,
   local_lock=none,addr=192.168.1.15)

Hiçbir sürüm belirtmedim, iki taraf vers=4.2 üzerinde anlaştı. sec=sys yine karşımda. Dosya paylaşımı bu noktada çalışır durumdadır ve çoğu kurulum burada biter. Asıl soru ise henüz sorulmadı: sunucu, bağlanan bu makinede oturan kişinin kim olduğunu neye bakarak anlıyor?

NFS’te Kimlik Bir Sayıdır: UID ve GID Modeli

Cevap kısa: NFS bağlanan kişiyi bir sayı olarak tanır. Kullanıcı adı, parola ya da grup adı ağa hiç çıkmaz. İstemci her istekle birlikte “bu isteği yapan kullanıcının numarası şu, grup numarası bu” diye bir bildirimde bulunur, sunucu da bu numaraları kendi dosya sistemindeki sahiplik bilgisiyle karşılaştırır.

Bu numaraların adı UID (User ID) ve GID (Group ID). Her Linux sisteminde zaten vardırlar; id komutu size kendinizinkini söyler:

id muhasebe

uid=1500(muhasebe) gid=1500(muhasebe) groups=1500(muhasebe)

Parantez içindeki isimler yerel bir kolaylıktır. Sistem dosyaları sahiplendirirken muhasebe yazmaz, 1500 yazar; ismi ekrana basarken /etc/passwd dosyasına bakıp numarayı isme çevirir. Aynı dosyaya ls -ln ile bakarsanız çeviri yapılmamış halini görürsünüz:

ls -l  /srv/paylasim/butce.txt
ls -ln /srv/paylasim/butce.txt

-rw-r--r-- 1 muhasebe muhasebe 19 Aug 13 16:07 /srv/paylasim/butce.txt
-rw-r--r-- 1 1500     1500     19 Aug 13 16:07 /srv/paylasim/butce.txt

İki satır aynı dosyayı anlatıyor. Üstteki insan için, alttaki gerçek.

Bildirimin Ağdaki Hali: AUTH_SYS

Bu noktada işin mekanizmasına inmek gerekiyor, çünkü “sunucu numaraya bakar” cümlesi tek başına kritik ayrıntıyı gizliyor: o numarayı sunucuya kim söylüyor?

Cevabı görmek için istemci yazma yaparken sunucudaki trafiği yakaladım:

sudo tcpdump -i ens33 -s 0 -w nfs-authsys.pcap "port 2049 or port 111"

Aşağıdaki dökümde bakılacak üç yer var, döküme geçmeden onları söyleyeyim:

• Flavor satırı: kimlik doğrulama yönteminin adı.
• UID ve GID satırları: isteği yapan kullanıcının kim olduğu iddiası.
• Verifier bloğu: bu iddianın kanıtı.

Yakalanan bir isteğin kimlik bölümü şöyle görünüyor:

Remote Procedure Call, Type:Call XID:0xcdadd49f
    Program: NFS (100003)
    Program Version: 4
    Procedure: COMPOUND (1)
    Credentials
        Flavor: AUTH_UNIX (1)
        Length: 32
        Stamp: 0x00000000
        Machine Name: openldap
        UID: 1500
        GID: 1500
        Auxiliary GIDs (1) [1500]
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0

Bu dökümün söylediklerini sırayla okuyalım:

1. Flavor: AUTH_UNIX (1), kullanılan kimlik yönteminin adıdır. Export çıktısındaki sec=sys ile aynı şeydir, literatürde çoğunlukla AUTH_SYS diye geçer.
2. Machine Name: openldap, isteği yapan makinenin kendi adıdır. İstemci bunu kendisi yazar.
3. UID: 1500 ve GID: 1500, kimlik iddiasının tamamıdır. Ortada bir kullanıcı adı yok, bir parola yok, bir bilet yok. Yalnız iki sayı.
4. Verifier bloğu boş. AUTH_NULL ve Length: 0, “bu iddiayı doğrulayan bir şey eklemedim” demektir.

Dördüncü madde bu makalenin en önemli teknik ayrıntısıdır. Protokolde kimlik iddiasının yanına bir kanıt koymak için ayrılmış bir alan var ve klasik kurulumda o alan boş gidiyor. Sunucu, istemcinin beyanını doğrulamıyor; çünkü doğrulayacak bir şey yok.

Aynı yakalamada uid=1500 taşıyan 22 çerçeve saydım. Hepsinde aynı manzara: numara açık, kanıt yok.

Eşleme Tablosu ve Analojinin Koptuğu Yer

Vestiyer benzetmesini ağdaki karşılıklarıyla yan yana koyalım, çünkü analojinin işe yaraması için hangi ilişkinin neye karşılık geldiğinin görünmesi gerekir:

Ve analojinin yalan söylediği yer şurası, söylemezsem yanlış bir güven duygusu bırakır: vestiyerde fişi göstermek için önce o fişe sahip olmanız gerekir. Kağıt parçasıdır, cebinizdedir, kaybederseniz sorun yaşarsınız. NFS’te ise numarayı “göstermek” için hiçbir şeye sahip olmanız gerekmez. Kendi makinenizde yönetici iseniz, istediğiniz numarayı yazarsınız ve o numara ağda öylece gider.

Bu soyut bir risk değil. Sıradaki bölümde önce bu çakışmanın kimse istemeden nasıl doğduğunu göstereceğim; ardından Hesap Bile Gerekmiyor başlığında aynı şeyi bilerek yapıp, istemcide hiçbir hesap açmadan yalnızca bir numara beyan ederek başkasına kapatılmış bir dosyayı okuyacağım.

NFS İzin Çakışması Nereden Doğar? Aynı Ad, Farklı Numara

İzin çakışmalarının kaynağı tek cümleyle şudur: kullanıcı numaraları makine başına dağıtılır, ama paylaşılan dosya sistemi ortaktır. Bir Linux sunucuda kullanıcı açtığınızda sistem sıradaki boş numarayı verir. İki ayrı sunucuda aynı sırayla kullanıcı açarsanız numaralar tesadüfen tutar; farklı sırayla açarsanız tutmaz. Hiçbir uyarı çıkmaz, çünkü iki makinenin birbirinden haberi yoktur.

Bunu lab ortamında bilerek üretmek için üç hesap açtım:

• Sunucuda muhasebe, numarası 1500.
• İstemcide muhasebe, numarası 1600. Adı aynı, numarası farklı.
• İstemcide ayrıca depo, numarası 1500. Adı farklı, numarası sunucudaki muhasebe ile aynı.

Sonra sunucuda muhasebe’ye ait bir dosya oluşturup istemciden bağlandım. Aynı dosya, iki makine:

Sayı iki tarafta da aynı, isim değişti. İsim zaten hiç ağa çıkmadı; her makine kendi /etc/passwd dosyasına bakıp 1500’ü kendi bildiği isme çevirdi.

Doğru İsimli Kullanıcı Yazamıyor, Yanlış İsimli Yazabiliyor

Asıl çarpıcı sonuç, iki kullanıcıya sırayla yazdırmaya çalıştığımda çıktı:

sudo -u muhasebe touch /mnt/paylasim/muhasebe-denemesi.txt
sudo -u depo     touch /mnt/paylasim/depo-denemesi.txt

touch: cannot touch '/mnt/paylasim/muhasebe-denemesi.txt': Permission denied

Ekranda tek satır var ve o da ilk komuta ait: ikincisi hiçbir şey yazmadan, yani sessizce başarılı oldu. Adı sunucudaki sahiple birebir aynı olan kullanıcı reddedildi. Adı hiç alakasız olan kullanıcı yazdı. Dosyanın sunucudaki hali ise şu:

-rw-rw-r-- 1 muhasebe muhasebe 0 Aug 13 16:08 depo-denemesi.txt

depo yazdı, sunucuda muhasebe’nin dosyası olarak duruyor. Vestiyerde başkasının numarasını uzatıp onun paltosunu almak buna benzer, ama önemli bir fark var: burada kimse başkasının numarasını almaya çalışmadı.

Bu çakışmayı ben labda bilerek kurdum. Sahada ise kendiliğinden oluşur ve hikâyesi genelde şudur: sunucuyu kuran yönetici o makinede muhasebe hesabını açar, sistem ona sıradaki boş numarayı verir. Aylar sonra bambaşka biri, bambaşka bir makinede depo hesabını açar; o sistem de kendi sırasındaki boş numarayı verir. İki numaranın aynı çıkması için kimsenin hata yapmış olması gerekmez: iki makine birbirine hiç sormaz, her biri kendi sayacından ilerler. Ortak bir klasör paylaşılana kadar da kimse fark etmez.

Hesap Bile Gerekmiyor

Bu noktada “numaraları hizalarım, biter” demek isteyebilirsiniz. Hizalamak işe yarar ama meselenin yalnız yarısını çözer, çünkü modelin dayandığı şey numaraların doğruluğu değil, istemciye duyulan güvendir.

Bunu göstermek için sunucuda yalnız orada var olan bir kullanıcı açtım: mudur, numarası 1501. Ona ait dizini 700, dosyayı 600 izinleriyle kapattım; yani sahibinden başkası ne girebilir ne okuyabilir. İstemcide 1501 numaralı hiçbir hesap yok:

getent passwd 1501

Komut hiçbir şey basmadı ve 2 çıkış koduyla döndü, yani “böyle bir kayıt yok” dedi.

Sonra istemciden, hiçbir hesap oluşturmadan, yalnızca numarayı beyan ederek okumayı denedim:

sudo -u depo cat /mnt/paylasim/mudur-ozel/ozel.txt
sudo setpriv --reuid 1501 --regid 1501 --clear-groups cat /mnt/paylasim/mudur-ozel/ozel.txt

cat: /mnt/paylasim/mudur-ozel/ozel.txt: Permission denied
sadece mudur okuyabilir

İkinci satır dosyanın içeriği. Parola yok, hesap yok, grup üyeliği yok. Yalnızca beyan edilen bir sayı ve sunucunun o beyanı kabul etmesi.

Kalıcı Çözüm: Numarayı Tek Yerden Dağıtmak

Çakışmayı elle numara hizalayarak çözmek üç makinede işe yarar, otuz makinede yürümez: her yeni sunucuda aynı sırayı tutturmanız gerekir ve bir kere kaydığında geriye dönüp binlerce dosyanın sahipliğini düzeltmek zorunda kalırsınız.

Kalıcı çözüm, kullanıcı numarasını makinelerin kendi kararına bırakmamak, merkezî bir dizinden dağıtmaktır. Bir dizin sunucusu her kullanıcıya bir kez numara verir, bütün makineler o numarayı aynı yerden okur ve muhasebe her sunucuda aynı sayıya karşılık gelir. Dizinin bu işi nasıl yaptığını, sorguların nasıl kurulduğunu ve şifresiz bir dizin bağlantısının neyi açığa çıkardığını LDAP nedir rehberimizde ele alıyoruz.

root_squash: NFS’te root’u Kapıda Karşılayan Ayar

Buraya kadarki kural basitti: numaranız neyse, sunucudaki dosya izinleri o numaraya göre uygulanır. Sahibiyseniz açarsınız, değilseniz açamazsınız.

Bir numara bu kurala uymaz: sıfır.

root, Linux’ta ayrı bir mekanizma değil, sadece numarası 0 olan kullanıcıdır. Farkı şurada: işletim sistemi 0 numarasıyla gelen bir istekte izinlere bakmaz bile. “Bu kullanıcının hakkı var mı?” sorusu hiç sorulmaz. Yani root, izinleri aşan biri değil, izin denetiminden muaf olan biridir.

Şimdi iki gerçeği yan yana koyun:

• NFS’te kimlik, istemcinin beyan ettiği bir sayıdır ve doğrulanmaz.
• 0 sayısı izin denetimini tamamen atlar.

Bunları çarpınca rahatsız edici sonuç çıkıyor: kendi makinesinde root olan herkes 0 beyan edebilir, beyan da doğrulanmadığına göre sunucuda dilediğini yapabilir. Yani birinin kendi bilgisayarında yönetici olması, kurumun dosya sunucusunda da yönetici olmasına yeterdi.

NFS bu açığı bilir ve varsayılan olarak kapalı gelir. Savunmanın adı root_squash; exportfs -v çıktısında yazmadığım halde karşıma çıkmasının sebebi buydu.

Türkçesi “ezmek” olan squash tam da yaptığı işi anlatıyor: gelen 0’ı kapıda yakalar ve hiçbir yetkisi olmayan bir kullanıcıya düşürür. Sunucu isteği reddetmez, ama isteği yapanı root saymaz.

Bunu ölçerken önce beklemediğim bir şey oldu: istemcinin root’u, muhasebe’ye ait sıradan bir dizine dosya yazamadı bile. Sebebi düşünülünce açık: nobody’ye düşürüldüğü için o dizinde artık “diğerleri” hakkıyla duruyordu ve o hakta yazma yoktu. Yani root burada ayrıcalıklı değil, ortamdaki en yetkisiz kullanıcı.

Düşürülmenin sonucunu görmek için herkesin yazabildiği bir dizin açtım ve orada tekrar denedim:

sudo touch /mnt/paylasim/herkese-acik/root-yazdi.txt

Bu sefer yazdı, ama sunucuda dosyanın sahibi root değil:

-rw-r--r-- 1 nobody nogroup 0 Aug 13 16:09 root-yazdi.txt
-rw-r--r-- 1 65534  65534   0 Aug 13 16:09 root-yazdi.txt

0 numarasıyla gelen istek, sunucuda 65534 numaralı nobody kullanıcısına düşürüldü. nobody, Linux’ta tam olarak bu iş için duran hesaptır: hiçbir gruba, hiçbir dosyaya ve hiçbir yetkiye bağlı değildir, kimliği düşürülen istekler oraya park edilir.

Aynı root, sahiplik değiştirmeyi denediğinde de duvara çarptı:

chown: changing ownership of '/mnt/paylasim/butce.txt': Operation not permitted

Vestiyer benzetmesinde bu, bankoya gelip sıraya girmek istemeyen, “benim kim olduğumu biliyor musunuz?” deyip torpil bekleyen kişiye görevlinin verdiği cevaptır: burada o iddianın bir karşılığı yok. Kendisi hakkında ne söylediğinin önemi de yok, çünkü söylediğini ispatlayan hiçbir şey getirmedi.

Üstelik sonuç, torpil bekleyenin umduğundan da kötü. nobody’ye düşürülen kişi sıradan bir müşteri bile sayılmaz: elinde hiç fiş yoktur. İçeri girebilir, herkese açık rafa bir şey bırakabilir, ama gösterecek numarası olmadığı için hiçbir paltoyu isteyemez. İstemcideki yetki, sunucunun kapısında biter.

no_root_squash Açıkken Ne Oluyor? Ölçülmüş Sonuç

root_squash’ı kapatan bir seçenek var: no_root_squash. Uygulamanın kurulum belgesi istediği ya da bir izin sorunu hızlıca aşılmak istendiği için sahada açıldığına rastlanır.

Şimdiye kadarki bütün ölçümler root_squash açıkken, yani sunucu kendini korurken yapıldı. Kapatınca neyin değiştiğini görmek için ayrı bir export açtım ve testleri orada yaptım; çalışan paylaşımı bozmak istemedim.

Sunucuya bir “gizli” dosya koydum: sahibi muhasebe, izni 600. Bu izin şunu söyler: sahibi okur ve yazar, başka hiç kimse açamaz. Sonra istemcinin root’uyla üç şey denedim.

1. Başkasına kapatılmış dosyayı okudu.

sudo cat /mnt/tehlikeli/mudur.txt

gizli mudur dosyasi

Dosyanın sahibi değilim, izin de kimseye açık değil. root_squash açık olsaydı bu istek nobody’ye düşürülür ve reddedilirdi.

2. Dosyanın sahibi oldu.

sudo chown root:root /mnt/tehlikeli/mudur.txt

Komut hiç itiraz etmeden çalıştı. Korumalı export’ta aynı komutun Operation not permitted aldığını bir önceki testte görmüştük.

3. Sunucuya setuid bitli bir dosya bıraktı.

sudo cp /bin/bash /mnt/tehlikeli/kabuk
sudo chmod 4755 /mnt/tehlikeli/kabuk

Sunucudaki sonuç:

-rwsr-xr-x 1 root root 1446024 Aug 13 16:09 kabuk

Üçüncüsü diğer ikisinden ciddi ve sebebi tek bir harfte saklı. Soldaki izin dizisinde normalde x olması gereken yerde s duruyor. Bu harfin adı setuid ve tek bir şey söyler: bu dosya çalıştırıldığında, çalıştıran kişinin yetkisiyle değil, dosyanın sahibinin yetkisiyle çalışır. Buradaki sahip root.

Buradan bir yetki yükseltme zinciri çıkıyor. Adım adım gidelim; her adımda dikkat edilecek şey, o an kimin elinde ne yetki olduğu:

1. İstemci makinede yönetici olan biri var. Bu kişi yalnız kendi makinesinin root’u. Sunucuda hiçbir yetkisi yok, orada hesabı bile olmayabilir. Ama no_root_squash yüzünden sunucu onun root beyanını kabul ediyor, yani paylaşıma root olarak yazabiliyor.
2. Dosyayı bırakıyor. Kopyaladığı şey sıradan bir kabuk programı. Sahibini root yapıp setuid bitini koyabiliyor, çünkü birinci adımda sunucu onu zaten root saydı.
3. Dosya sunucunun diskinde kalıyor. İstemci makine kapansa, kablosu çekilse, o kişi ağdan tamamen çıksa bile dosya orada durur. Bırakılan şey geçici bir erişim değil, kalıcı bir araç.
4. Sunucuda sıradan bir kullanıcı o dosyayı çalıştırıyor. Bu kişinin hiçbir özel yetkisi yok, normal bir hesap. Ama setuid biti yüzünden program, onu çalıştıranın değil sahibinin yetkisiyle başlıyor. Sahibi root.
5. O sıradan kullanıcı artık root olarak iş yapıyor. Yetki yükseltme tam olarak burada gerçekleşiyor: normal bir hesapla giren biri, tek bir dosyayı çalıştırarak sunucunun tam yetkisine çıkıyor.

Zincirin en rahatsız edici tarafı şu: baştaki kişiyle sondaki kişinin aynı olması gerekmiyor. Dosyayı bırakan çoktan gitmiş olabilir, çalıştıran ise olan bitenden habersiz biri olabilir. Kaybedilen şey bir dosyaya erişim değil, sunucunun kapısının kendisi. Vestiyer benzetmesinde root_squash, “ben buranın müdürüyüm” iddiasını kapıda geçersiz kılan kuraldı; no_root_squash o kuralı kaldırır ve dışarıdan gelen kişi gerçekten müdür sayılır. Bıraktığı setuid dosyanın karşılığı da şu: arka odaya kendi görevli önlüğünü asıp gider. O önlüğü giyen herkes, o günden sonra görevli muamelesi görür.

Ölçümü aldıktan sonra bu dosyayı sildim ve export’u kaldırdım: laboratuvarda bile setuid bitli bir kabuk ortalıkta bırakılmaz.

all_squash: Herkesi Tek Kişiye İndirmek

Üçüncü bir seçenek daha var ve amacı farklı: all_squash yalnız root’u değil gelen bütün numaraları tek bir kullanıcıya indirir. Hangi kullanıcı olacağı anonuid ve anongid ile söylenir.

Bunu da ölçtüm. Export satırı şu:

/srv/ortak  192.168.1.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1500,anongid=1500)

Ardından istemciden üç ayrı kimlikle yazdım: depo (1500), muhasebe (1600) ve root (0). Sunucudaki sonuç:

-rw-rw-r-- 1 muhasebe muhasebe 0 depo.txt
-rw-rw-r-- 1 muhasebe muhasebe 0 muhasebe.txt
-rw-r--r-- 1 muhasebe muhasebe 0 root.txt

Üç farklı kimlik, tek sahip. Bu bir güvenlik önlemi değil, bir basitleştirmedir: kimin ne yaptığını ayırt etmekten vazgeçip herkesi aynı kişi saymak. Yeri, kimlik ayrımının gerçekten gereksiz olduğu paylaşımlardır: ortak bir medya dizini, bir yedek hedefi, salt okunur dağıtılan bir kurulum deposu. Kişiye göre yetki verilmesi gereken bir paylaşımda kullanılırsa denetim izini tamamen kaybedersiniz, çünkü kayıtlarda herkes aynı kullanıcı olarak görünür.

Üç seçeneğin yan yana hâli şöyle:

NFS Sürümleri: v3, v4 ve sec=krb5 ile Kimliğin İsme Dönmesi

Buraya kadar anlatılan her şey sec=sys, yani AUTH_SYS kurulumunun kurallarıydı. Şimdi haklı bir itirazın sırası: NFS’in yeni sürümü var, o da mı böyle çalışıyor?

Bugün sahada iki sürüm görürsünüz ve aralarındaki fark sadece hız değildir:

• NFSv3 eski ve hâlâ yaygın olan sürümdür. Yardımcı servislere ihtiyaç duyar: bağlantı kurulurken rpcbind (port 111) üzerinden hangi servisin hangi portta olduğu sorulur, kilitleme ayrı bir servisle yürür. Firewall arkasında yapılandırması bu yüzden sinir bozucudur, çünkü açılacak port tek değildir.
• NFSv4 işi tek porta topladı: 2049. Yardımcı servisler protokolün içine alındı, kilitleme dahil edildi, birden çok işlem tek istekte gönderilebilir hale geldi. Yakalamamdaki Procedure: COMPOUND satırı bunun izidir. Ayrıca bir güvenlik çerçevesi tanımlandı ve kimliğin sayı yerine kullanici@alan biçiminde bir isim olarak taşınması öngörüldü. Sürümün tam tanımı RFC 8881 belgesinde duruyor.

Son cümle umut verici görünüyor ve tam da bu yüzden ölçtüm. Lab bağlantım vers=4.2 ile kurulmuştu, yani en güncel sürüm. Ağda sahiplik alanı isim olarak mı gidiyor? Yakaladığım trafikten sahiplik alanlarını çektim:

tshark -r nfs-authsys.pcap -T fields -e nfs.fattr4_owner -e nfs.fattr4_owner_group

1500    1500

Hayır. NFSv4.2 ile bağlıyım ve sahiplik alanı yine 1500 taşıyor, muhasebe@ad.sistemkusu.com değil. Sebebi istemcinin kendi ayarında yazıyordu:

cat /sys/module/nfs/parameters/nfs4_disable_idmapping

Y

İsim çevirisi, AUTH_SYS ile çalışırken varsayılan olarak kapalı. Mantığı da tutarlı: kimlik zaten sayı olarak doğrulanıyorsa, onu isme çevirip geri çevirmek yalnız iş yükü ve yeni hata kaynağı olurdu.

O halde isim ne zaman gerçekten devreye giriyor? Kimlik doğrulaması sayıdan çıkıp kanıta bağlandığında. Bunun yolu mount seçeneğini sec=krb5 yapmaktır: istemci artık “ben 1500 numaralıyım” demez, Kerberos’tan aldığı bir bileti sunar ve sunucu o bileti doğrular. Boş duran Verifier alanı işte o zaman dolar. Vestiyer benzetmesinde bu, fişin üstüne taklit edilemeyen bir mühür basmaktır: numara hâlâ oradadır, ama artık numarayı yazmak yetmez.

Bilet mantığının nasıl işlediğini ve doğrulamanın hangi adımlardan geçtiğini Kerberos nedir rehberimizde ele alıyoruz.

NFS ve SMB Yan Yana: Aynı Klasöre İki Kapı

Şimdi ebeveyn makalemizin bıraktığı asıl soruya gelebiliriz: aynı NAS cihazı aynı klasörü Windows istemcilere SMB, Linux sunuculara NFS ile sunabilir. Peki iki protokol aynı dosyaya baktığında yetki nasıl hesaplanır?

Cevap şudur ve sorunun tamamı buradadır: ikisi kullanıcıyı farklı şeyle tanır.

SMB tarafında görevli adınızı bilir ve üye defterine bakar. NFS tarafında görevli yalnız numaranızı bilir. Aynı paltoyu iki farklı sisteme göre teslim etmeye çalışan bir vestiyer düşünün: bir kapıda kimlik soruluyor, diğerinde numara.

Bu yüzden çift protokollü paylaşımda kritik ayar, cihazın kimlik eşleme yapılandırmasıdır: NAS cihazı hangi Active Directory kullanıcısının hangi sayısal numaraya karşılık geleceğini bilmelidir. Bu eşleme kurulmazsa belirti tipik olarak şudur: Windows tarafından açılan dosya Linux tarafında sahipsiz ya da nobody görünür, Linux tarafından yazılan dosyaya Windows kullanıcısı erişemez, ve her iki tarafın yöneticisi de kendi tarafında izinlerin doğru olduğunu görür.

SMB’nin kendi tarafındaki yetki katmanlarını, paylaşım izni ile NTFS izninin nasıl kesiştiğini ve domain ortamındaki rolünü SMB nedir rehberimizde ele alıyoruz.

Çift Protokol Açılmalı mı?

Açılabilir olması açılması gerektiği anlamına gelmiyor. Karar için işe yarayan ölçüt, aynı dosyaya iki taraftan da yazılıp yazılmayacağıdır:

• İki taraf da yazacaksa kimlik eşlemesi kurulmadan açmayın. Kurulmadığında ortaya çıkan izin çakışmaları, dosyalar zaten oluştuktan sonra düzeltilir ve bu geriye dönük bir temizlik işidir.
• Bir taraf yazıp diğeri yalnız okuyacaksa iş belirgin şekilde kolaylaşır. Okuyan tarafa salt okunur export vermek çakışma ihtimalinin çoğunu ortadan kaldırır.
• İki tarafın işi birbirinden bağımsızsa en sağlam yol aynı klasörü paylaştırmamaktır. İki ayrı paylaşım açmak, tek paylaşımı iki kimlik modeliyle uzlaştırmaya çalışmaktan hem ucuz hem kararlıdır.

Storage kutusunun kendisini seçerken sorulan sorular ise ayrı bir konudur: dosya düzeyinde mi blok düzeyinde mi erişileceği, kaç disk yuvası gerektiği, yedekliliğin nasıl kurulacağı. Bu kararı BT sistem yönetimi sayfamızın storage sistemleri bölümünde ele alıyoruz; bu makale kutunun içindeki protokolü anlatıyor, kutunun seçimini değil.

Sanallaştırmada NFS Datastore

NFS’i en çok göreceğiniz ikinci yer sanallaştırma ortamlarıdır. Hypervisor, sanal makinelerin disk dosyalarını bir storage alanında tutar ve bu alanı NFS üzerinden bağlamak yaygın bir tercihtir: kurulumu blok düzeyinde bir storage ağı kurmaktan belirgin şekilde basittir, dosyalar dosya olarak durduğu için yedekleme ve taşıma tarafında elinizi rahatlatır.

Buraya kadar anlattığımız kimlik modeli burada beklenmedik bir yerden geri geliyor. Hypervisor, sanal disk dosyalarına root olarak erişir. Yani root_squash tam olarak burada devreye girer ve datastore’un çalışmasını engeller. Bu yüzden sanallaştırma için verilen export’larda no_root_squash sık karşılaşılan bir yapılandırmadır.

Bu, o seçeneğin tehlikeli olmaktan çıktığı anlamına gelmiyor; koşulunun sağlandığı anlamına geliyor. Hatırlayın: no_root_squash’ın meşru olmasının şartı, istemcinin sunucu kadar güvenilir olmasıydı. Hypervisor tam olarak öyle bir makinedir ve storage trafiği ayrı bir ağ segmentinde tutulur. Yani buradaki güvenlik, export seçeneğinden değil, o segmente kimin girebildiğinden gelir.

Hypervisor’ün storage’ı nasıl kullandığını, datastore kavramını ve boyutlandırma kararlarını sanallaştırma ve hypervisor rehberimizde ele alıyoruz. Paylaşımlı storage’ıyla birlikte bir sanallaştırma altyapısını kurduğumuz iş için sanallaştırma kurulum hizmetimize bakabilirsiniz.

NFS Teşhisi: Bağlanıyor Ama Yazamıyor

NFS arızalarının çoğu üç katmandan birindedir ve teşhis alttan üste doğru yapılır. Üstteki katmana bakmadan önce alttakinin sağlam olduğundan emin olun, yoksa izinlerle uğraşırken sorunun ağda olduğunu saatler sonra fark edersiniz.

1. Ağ katmanı: sunucuya ulaşılıyor mu?

showmount -e 192.168.1.15

Bu komut cevap veriyorsa hem ağ hem NFS servisi ayaktadır. Cevap vermiyorsa sorun izinlerde değil: servis kapalı, 2049 numaralı port kapalı ya da isim çözümlemesi yanlış makineye gidiyordur. NFSv3 kullanıyorsanız 111 numaralı portun da açık olması gerekir.

2. Export katmanı: bu makineye izin verilmiş mi?

showmount çıktısı export’un hangi ağa açıldığını yazar. İstemcinizin adresi o aralığın dışındaysa mount reddedilir. En sık yapılan hata, export satırında tek bir adres tanımlıyken istemcinin başka bir arayüzden çıkması, yani sunucuya beklenenden farklı bir kaynak adresle görünmesidir.

Sunucu tarafında gerçekte neyin yürürlükte olduğunu her zaman exportfs -v ile teyit edin. Dosyayı düzenleyip exportfs -ra çalıştırmayı unutmak, “değiştirdim ama olmadı” vakalarının klasik sebebidir.

3. Kimlik katmanı: izin görünüyor ama yazamıyor.

Bu, NFS’e en özgü arıza ve bu makalenin en başından beri anlatılan şeyin sahadaki hâli. Belirti kafa karıştırıcıdır: dosyayı görürsünüz, sahibi olarak tanıdık bir isim yazar, ama yazmaya çalıştığınızda reddedilirsiniz.

Bakılacak yer izin listesi değil, numaradır:

id
ls -ln /mnt/paylasim

ls -l yerine ls -ln kullanmak burada bir tercih değil, teşhisin kendisidir. ls -l size kendi makinenizin çevirisini gösterir ve tam da yanıltan şey odur. ls -ln çevrilmemiş sayıyı verir; kendi id çıktınızdaki sayıyla karşılaştırdığınızda uyuşmuyorsa cevabı bulmuşsunuzdur.

Belirtiye göre nereye bakılacağı şöyle özetlenebilir:

Son bir uyarı: sunucu tarafında bir kullanıcının numarasını değiştirmek, o kullanıcıya ait dosyaların sahipliğini değiştirmez. Dosyalar eski numarayı taşımaya devam eder ve o numarayı sonradan kim devralırsa dosyalar onun olur. Kullanıcı numarası değiştirmek isteyen biri, aynı işlemde dosya sahipliklerini de taramak zorundadır.

Sonuç: NFS Kullanıcıyı Adıyla Değil Numarasıyla Tanır

NFS’i doğru kullanmanın yolu, onu güvensiz bir protokol saymaktan değil, neye güvendiğini bilmekten geçiyor. Klasik kurulumda sunucu, istemcinin bildirdiği kullanıcı numarasını doğrulamadan kabul eder ve bunu bir açık olarak değil, tasarım tercihi olarak yapar: güvenilen bir ağda, yönetimi tek elde olan makineler arasında bu model hızlı ve sürtünmesiz çalışır.

Sorunlar bu varsayımın sessizce bozulduğu yerde başlıyor. Numaralar makine başına dağıtıldığı için iki sunucu farklı sıralarla kullanıcı açtığında aynı sayı iki ayrı kişiyi işaret etmeye başlar; kimse yanlış bir şey yapmamıştır ve hiçbir uyarı çıkmaz. Aynı klasör bir de SMB ile paylaştırıldığında, kullanıcıyı adıyla tanıyan bir model ile numarasıyla tanıyan bir model aynı dosyanın üstünde buluşur.

Vestiyer görevlisi numaraya bakar, paltoyu verir ve doğru kişiye verdiğini varsayar. Bu varsayımın geçerli olduğu yerde sistem kusursuz işler. Geçerli olmadığı yerde ise ortaya çıkan belirti neredeyse hiçbir zaman “kimlik” gibi görünmez; “izin var ama yazamıyorum” gibi görünür ve saatler o yanlış yerde harcanır.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn