Azure NetApp Files'da NFSv4.x erişim denetim listelerini anlama
NFSv4.x protokolü, Windows NTFS izinleri aracılığıyla SMB'de kullanılan ACL'lere kavramsal olarak benzeyen erişim denetim listeleri (ACL' ler) biçiminde erişim denetimi sağlayabilir. NFSv4.x ACL'leri, her biri sunucuya bir erişim denetimi yönergesi sağlayan tek tek Erişim Denetimi Girdilerinden (ACL) oluşur.
Her NFSv4.x ACL,biçiminde type:flags:principal:permissionsoluşturulur.
- Tür – tanımlanan ACL'nin türü. Geçerli seçenekler şunlardır: Erişim (A), Reddetme (D), Denetim (U), Alarm (L). Azure NetApp Files Access, Deny ve Audit ACL türlerini destekler, ancak ACL'leri Denetle ayarlanabiliyorken şu anda denetim günlükleri oluşturmaz.
- Bayraklar : ACL için ek bağlam ekler. Üç tür ACE bayrağı vardır: grup, devralma ve yönetim. Bayraklar hakkında daha fazla bilgi için bkz . NFSv4.x ACE bayrakları.
- Principal – ACL'ye atanan kullanıcıyı veya grubu tanımlar. NFSv4.x ACL'sinde sorumlu, name@ID-DOMAIN-STRING.COMbiçimini kullanır. Sorumlular hakkında daha ayrıntılı bilgi için bkz . NFSv4.x kullanıcı ve grup sorumluları.
- İzinler – sorumlunun erişim düzeyinin tanımlandığı yer. Her izin tek bir harf olarak atanır (örneğin, okuma "r" alır, yazma "w" alır vb.). Tam erişim, kullanılabilir her bir izin mektubunu içerir. Daha fazla bilgi için bkz . NFSv4.x izinleri.
A:g:group1@contoso.com:rwatTnNcCy , biçimi izleyen geçerli bir ACL örneğidir type:flags:principal:permissions . Örnek ACL, contoso.com Kimliği etki alanındaki gruba group1 tam erişim verir.
NFSv4.x ACE bayrakları
ACE bayrağı, ACL'deki ACE hakkında daha fazla bilgi sağlamaya yardımcı olur. Örneğin, ACL'ye bir grup ACE'i eklenirse, sorumlunun kullanıcı değil grup olduğunu tanımlamak için bir grup bayrağının kullanılması gerekir. Linux ortamlarında aynı kullanıcı ve grup adı olması mümkündür, bu nedenle bayrağı bir ACE'nin yerine getirilmesini sağlar, ardından NFS sunucusunun ne tür bir sorumlu tanımlandığını bilmesi gerekir.
Devralma ve yönetim bayrakları gibi ACL'leri denetlemek için diğer bayraklar kullanılabilir.
Erişim ve reddetme bayrakları
Güvenlik ACE türlerini denetlemek için Erişim (A) ve reddetme (D) bayrakları kullanılır. Erişim ACE'i, bir sorumlu için bir dosya veya klasördeki erişim izinlerinin düzeyini denetler. Reddetme ACE'i, sorumlunun nesneye erişmesine izin verecek bir erişim ACE'i ayarlanmış olsa bile, sorumlunun bir dosyaya veya klasöre erişmesini açıkça yasaklar. ACL'lere her zaman erişimi reddeder. Genel olarak, NFSv4.x ACL'leri "varsayılan reddetme" modelini izlediğinden reddetme ACL'lerini kullanmaktan kaçının; yani ACL eklenmediyse reddetme örtük olur. Reddetme ACL'leri ACL yönetiminde gereksiz komplikasyonlar oluşturabilir.
Devralma bayrakları
Devralma bayrakları, devralma bayrağı ayarlanmış bir üst dizin altında oluşturulan dosyalarda ACL'lerin nasıl davranacağını denetler. Devralma bayrağı ayarlandığında, dosyalar ve/veya dizinler ACL'leri üst klasörden devralır. Devralma bayrakları yalnızca dizinlere uygulanabilir, bu nedenle bir alt dizin oluşturulduğunda bayrağı devralır. Devralma bayrağıyla bir üst dizinin altında oluşturulan dosyalar ACL'leri devralır, ancak devralma bayraklarını devralmaz.
Aşağıdaki tabloda kullanılabilir devralma bayrakları ve bunların davranışları açıklanmaktadır.
| Devralma bayrağı | Davranış |
|---|---|
| d | - Üst dizinin altındaki dizinler ACL'yi devralır - Devralma bayrağı da devralındı |
| f | - Üst dizinin altındaki dosyalar ACL'yi devralır - Dosyalar devralma bayrağı ayarlamaz |
| ı | Salt devral; ACL geçerli dizine uygulanmaz, ancak dizinin altındaki nesnelere devralma uygulamalıdır |
| n | - Devralma yayılımı yok ACL devralındıktan sonra, üst öğe altındaki nesnelerde devralma bayrakları temizlenir |
NFSv4.x ACL örnekleri
Aşağıdaki örnekte, ayrı devralma bayraklarına sahip üç farklı ACL vardır:
- yalnızca dizin devralma (di)
- yalnızca dosya devral (fi)
- hem dosya hem de dizin devralma (fdi)
# nfs4_getfacl acl-dir
# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
User1 yalnızca ACL devralan bir dizine sahiptir. Üst dizinin altında oluşturulan bir alt dizinde ACL devralınır, ancak üst dizinin altındaki bir dosyada devralınmıyor.
# nfs4_getfacl acl-dir/inherit-dir
# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl acl-dir/inherit-file
# file: acl-dir/inherit-file
<< ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy
User2 bir dosyaya ve dizin devralma bayrağına sahiptir. Sonuç olarak, ace girdisine sahip bir dizinin altındaki hem dosyalar hem de dizinler ACL'yi devralır, ancak dosyalar bayrağı devralamaz.
# nfs4_getfacl acl-dir/inherit-dir
# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl acl-dir/inherit-file
# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy
User3 yalnızca bir dosya devral bayrağı var. Sonuç olarak, yalnızca ace girdisine sahip dizinin altındaki dosyalar ACL'yi devralır, ancak yalnızca dizin ACL'lerine uygulanabildiğinden bayrağı devralmaz.
# nfs4_getfacl acl-dir/inherit-dir
# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl acl-dir/inherit-file
# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy
ACL'de "propogate yok" (n) bayrağı ayarlandığında, üst dizinin altındaki sonraki dizin oluşturma işlemlerinde bayraklar temizlenir. Aşağıdaki örnekte user2 bayrağı ayarlanmıştır n . Sonuç olarak, alt dizin bu sorumlunun devralma bayraklarını temizler ve bu alt dizinde oluşturulan nesneler ACE'yi öğesinden user2devralmaz.
# nfs4_getfacl /mnt/acl-dir
# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# nfs4_getfacl inherit-dir/
# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
# mkdir subdir
# nfs4_getfacl subdir
# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy
Devral bayrağı, NFSv4.x ACL'lerinizi daha kolay yönetmenin bir yoludur ve her ihtiyacınız olduğunda açıkça bir ACL ayarlamanızı önler.
Yönetici istrative bayrakları
NFSv4.x ACL'lerindeki Yönetici istrative bayrakları yalnızca Denetim ve Alarm ACL türleriyle kullanılan özel bayraklardır. Bu bayraklar gerçekleştirilecek eylemler için başarı (S) veya başarısızlık (F) erişim girişimlerini tanımlar.
Azure NetApp Files, Denetim ACL'leri için yönetim bayrakları ayarlamayı destekler, ancak ACL'ler çalışmaz. Buna ek olarak, Alarm ACL'leri Azure NetApp Files'da desteklenmez.
NFSv4.x kullanıcı ve grup sorumluları
NFSv4.x ACL'leri ile, kullanıcı ve grup sorumluları ACE'nin uygulanması gereken belirli nesneleri tanımlar. Sorumlular genellikle biçimini izler name@ID-DOMAIN-STRING.COM. Bir sorumlunun "ad" bölümü bir kullanıcı veya grup olabilir, ancak NFSv4.x KIMLIK etki alanı belirtilirken bu kullanıcı veya grubun LDAP sunucu bağlantısı aracılığıyla Azure NetApp Files'da çözümlenebilir olması gerekir. name@domain Azure NetApp Files tarafından çözümlenemiyorsa, ACL işlemi "geçersiz bağımsız değişken" hatasıyla başarısız olur.
# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument
Ldap grup kimliği listesi kullanılarak bir adın çözümlenip çözümlenemediğini Azure NetApp Files içinde de kontrol edebilirsiniz. Destek + Sorun Giderme'ye ve ardından LDAP Grup Kimliği listesine gidin.
NFSv4.x ACL'leri aracılığıyla yerel kullanıcı ve grup erişimi
Yerel kullanıcılar ve gruplar, ACL'de yalnızca sayısal kimlik belirtilmişse NFSv4.x ACL'de de kullanılabilir. Etki alanı kimliği belirtilen kullanıcı adları veya sayısal kimlikler başarısız olur.
Örneğin:
# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy
# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument
# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument
Yerel bir kullanıcı veya grup ACL'si ayarlandığında, ACL'de sayısal kimliğine karşılık gelen tüm kullanıcılar veya gruplar nesneye erişim alır. Yerel grup ACL'leri için kullanıcı grup üyeliklerini Azure NetApp Files'a geçirir. Kullanıcının isteği aracılığıyla dosyaya erişimi olan grubun sayısal kimliği Azure NetApp Files NFS sunucusuna gösteriliyorsa, ACL'ye göre erişime izin verilir.
İstemciden sunucuya geçirilen kimlik bilgileri, aşağıda görüldüğü gibi paket yakalama yoluyla görülebilir.
Uyarılar:
- ACL'ler için yerel kullanıcıların ve grupların kullanılması, dosyalara/klasörlere erişen her istemcinin eşleşen kullanıcı ve grup kimliklerine sahip olması gerektiği anlamına gelir.
- Azure NetApp Files, ACL için sayısal bir kimlik kullanırken, gelen isteğin geçerli olduğuna ve erişim isteyen kullanıcının söyledikleri kişi olduğuna ve üyesi olduğunu iddia ettikleri grupların üyesi olduğuna örtük olarak güvenir. Hatalı bir aktör sayısal kimliği biliyorsa ve yerel olarak kullanıcı ve grup oluşturma özelliğine sahip bir istemci kullanarak ağa erişebiliyorsa kullanıcı veya grup sayısalı sahte olabilir.
- Bir kullanıcı 16'dan fazla grubun üyesiyse, LDAP ve genişletilmiş grup desteği kullanılmadığı sürece onaltıncı gruptan sonraki (alfasayısal sırayla) herhangi bir grubun dosya veya klasöre erişimi reddedilir.
- Daha iyi yönetilebilirlik ve güvenlik için NFSv4.x ACL'leri kullanılırken LDAP ve tam name@domain ad dizeleri kesinlikle önerilir. Merkezi olarak yönetilen bir kullanıcı ve grup deposunun bakımı daha kolaydır ve sahtekarlık yapmak daha zordur, bu nedenle istenmeyen kullanıcı erişiminin daha az olası olmasını sağlar.
NFSv4.x kimliği etki alanı
Kimlik etki alanı, kullanıcı ve grup adlarının (özellikle kök) dosya/klasör sahipliklerinde düzgün görünmesi için kimlik etki alanının hem istemcide hem de Azure NetApp Files içinde eşleşmesi gereken önemli bir bileşendir.
Azure NetApp Files, NFSv4.x kimlik etki alanını varsayılan olarak birimin DNS etki alanı ayarlarına ayarlar. NFS istemcileri ayrıca NFSv4.x kimlik etki alanı için DNS etki alanını da varsayılan olarak kullanır. İstemcinin DNS etki alanı Azure NetApp Files DNS etki alanından farklıysa bir uyuşmazlık oluşur. gibi lskomutlarla dosya izinleri listelenirken kullanıcılar/gruplar "hiç kimse" olarak gösterilir.
NFS istemcisi ile Azure NetApp Files arasında bir etki alanı uyuşmazlığı oluştuğunda, istemci günlüklerinde aşağıdakine benzer hatalar olup olmadığını denetleyin:
August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'
NFS istemcisinin kimlik etki alanı /etc/idmapd.conf dosyasının "Etki Alanı" ayarı kullanılarak geçersiz kılınabilir. Örneğin: Domain = CONTOSO.COM.
Azure NetApp Files ayrıca NFSv4.1 kimlik etki alanını değiştirmenize de olanak tanır. Ek ayrıntılar için bkz . Nasıl yapılır: Azure NetApp Files için NFSv4.1 Kimlik Etki Alanı Yapılandırması.
NFSv4.x izinleri
NFSv4.x izinleri, belirli bir kullanıcı veya grup sorumlusunun dosya veya klasör üzerindeki erişim düzeyini denetlemenin yoludur. NFSv3'teki izinler yalnızca erişim tanımının okuma/yazma/yürütme (rwx) düzeylerine izin verir, ancak NFSv4.x, NFSv3 modu bitlerine göre geliştirme olarak diğer ayrıntılı erişim denetimlerini içerir.
Kullanıcılar için ayarlanabilen 13 izin ve gruplar için ayarlanabilen 14 izin vardır.
| İzin mektubu | İzin verildi |
|---|---|
| r | Verileri okuma/dosya ve klasörleri listeleme |
| w | Veri yazma/dosya ve klasör oluşturma |
| a | Veri ekleme/alt dizin oluşturma |
| x | Dosyaları yürütme/dizinleri çapraz geçiş yapma |
| d | Dosyaları/dizinleri silme |
| D | Alt dizinleri silme (yalnızca dizinler) |
| t | Öznitelikleri okuma (GETATTR) |
| T | Yazma öznitelikleri (SETATTR/chmod) |
| n | Adlandırılmış öznitelikleri okuma |
| N | Adlandırılmış öznitelikleri yazma |
| c | ACL'leri okuma |
| C | ACL yazma |
| o | Yazma sahibi (chown) |
| y | Zaman Uyumlu G/Ç |
Erişim izinleri ayarlandığında, bir kullanıcı veya grup sorumlusu atanan haklara bağlı olur.
NFSv4.x izin örnekleri
Aşağıdaki örneklerde farklı izinlerin farklı yapılandırma senaryolarıyla nasıl çalıştığı gösterilmektedir.
Okuma erişimi olan kullanıcı (yalnızca r)
Salt okunur erişim sayesinde kullanıcı öznitelikleri ve verileri okuyabilir, ancak tüm yazma erişimi (veriler, öznitelikler, sahip) reddedilir.
A::user1@CONTOSO.COM:r
sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root 0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text
Okuma erişimi (r) ve yazma öznitelikleri (T) olan kullanıcı
Bu örnekte, yazma öznitelikleri (T) izni nedeniyle dosya üzerindeki izinler değiştirilebilir, ancak yalnızca okuma erişimine izin verildiğinden hiçbir dosya oluşturulamaz. Bu yapılandırma, NFSv4.x ACL'lerinin sağlayabilecekleri ayrıntılı denetim türlerini gösterir.
A::user1@CONTOSO.COM:rT
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x 3 root root 4096 Jul 12 16:23 .
drwxr-xr-x 19 root root 49152 Jul 11 09:56 ..
-rw-r--r-- 1 root root 10 Jul 12 16:22 file
drwxr-xr-x 3 root root 4096 Jul 12 12:41 inherit-dir
-rw-r--r-- 1 user1 group1 0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x 3 root root 4096 Jul 12 16:41 .
drwxr-xr-x 19 root root 49152 Jul 11 09:56 ..
drwxr-xr-x 3 root root 4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx 1 user1 group1 0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied
Mod bitlerini NFSv4.x ACL izinlerine çevirme
Bir chmod, NFSv4.x ACL'leri atanmış bir nesne çalıştırıldığında, bir dizi sistem ACL'si yeni izinlerle güncelleştirilir. Örneğin, izinler 755 olarak ayarlanırsa sistem ACL dosyaları güncelleştirilir. Aşağıdaki tabloda, bir mod bitindeki her sayısal değerin NFSv4 ACL izinlerinde neye çevrildiği gösterilmektedir.
Tüm izinleri ana hatlarıyla belirten bir tablo için bkz. NFSv4.x izinleri.
| Mod bit sayısalı | İlgili NFSv4.x izinleri |
|---|---|
| 1 – yürütme (x) | Yürütme, öznitelikleri okuma, ACL'leri okuma, G/Ç'yi eşitleme (xtcy) |
| 2 – yazma (w) | Yazma, verileri ekleme, öznitelikleri okuma, öznitelikleri yazma, adlandırılmış öznitelikleri yazma, ACL'leri okuma, G/Ç'yi eşitleme (watTNcy) |
| 3 – yazma/yürütme (wx) | Yazma, verileri ekleme, yürütme, öznitelikleri okuma, öznitelikleri yazma, adlandırılmış öznitelikleri yazma, ACL'leri okuma, G/Ç eşitleme (waxtTNcy) |
| 4 – okuma (r) | Okuma, öznitelikleri okuma, adlandırılmış öznitelikleri okuma, ACL'leri okuma, G/Ç'yi eşitleme (rtncy) |
| 5 – okuma/yürütme (rx) | Okuma, yürütme, öznitelikleri okuma, adlandırılmış öznitelikleri okuma, ACL'leri okuma, G/Ç'yi eşitleme (rxtncy) |
| 6 – okuma/yazma (rw) | Okuma, yazma, verileri ekleme, öznitelikleri okuma, öznitelikleri yazma, adlandırılmış öznitelikleri okuma, adlandırılmış öznitelikleri yazma, ACL'leri okuma, G/Ç'yi eşitleme (rwatTnNcy) |
| 7 – okuma/yazma/yürütme (rwx) | Tam denetim/tüm izinler |
NFSv4.x ACL'leri Azure NetApp Files ile nasıl çalışır?
Azure NetApp Files, bir birimde erişim için NFSv4.1 etkinleştirildiğinde NFSv4.x ACL'lerini yerel olarak destekler. ACL desteği için birimde etkinleştirecek bir şey yoktur, ancak NFSv4.1 ACL'lerinin en iyi şekilde çalışması için, Azure NetApp Files'ın ACL'lerde ayarlanan sorumluları güvenli bir şekilde çözümleyebilmesi için UNIX kullanıcıları ve gruplarına sahip bir LDAP sunucusu gerekir. Yerel kullanıcılar NFSv4.x ACL'leri ile kullanılabilir, ancak LDAP sunucusuyla kullanılan ACL'lerle aynı güvenlik düzeyini sağlamaz.
Azure NetApp Files'da ACL işlevselliğiyle ilgili dikkat edilmesi gereken noktalar vardır.
ACL devralma
Azure NetApp Files'da ACL devralma bayrakları, NFSv4.x ACL'ler ile ACL yönetimini basitleştirmek için kullanılabilir. Devralma bayrağı ayarlandığında, üst dizindeki ACL'ler daha fazla etkileşime gerek kalmadan alt dizinlere ve dosyalara yayılabilir. Azure NetApp Files, RFC-7530'a göre standart ACL devralma davranışları uygular.
ACL'leri reddet
Azure NetApp Files'daki ACL'leri reddetme, bir kullanıcının veya grubun bir dosyaya veya klasöre erişmesini açıkça kısıtlamak için kullanılır. reddetme ACE'sinde ayrıntılı denetimler sağlamak için bir izin alt kümesi tanımlanabilir. Bunlar RFC-7530'da belirtilen standart yöntemlerle çalışır.
ACL koruması
Azure NetApp Files'daki bir dosya veya klasörde chmod gerçekleştirildiğinde, sistem ACL'leri (OWNER@, GROUP@, EVERYONE@) dışındaki tüm mevcut ACL'ler ACL'de korunur. Bu ACE izinleri, chmod komutu tarafından tanımlanan sayısal mod bitleri tarafından tanımlandığı şekilde değiştirilir. Yalnızca komut aracılığıyla nfs4_setfacl el ile değiştirilen veya kaldırılan ACL'ler değiştirilebilir.
Çift protokollü ortamlarda NFSv4.x ACL davranışları
İkili protokol, aynı Azure NetApp Files biriminde hem SMB hem de NFS kullanımını ifade eder. çift protokollü erişim denetimleri, birimin hangi güvenlik stilini kullandığına göre belirlenir, ancak kullanıcı adı eşlemesi, başarıyla birbiriyle eşlenen Windows kullanıcılarının ve UNIX kullanıcılarının verilere aynı erişim izinlerine sahip olmasını sağlar.
NFSv4.x ACL'leri UNIX güvenlik stili birimlerinde kullanımda olduğunda, çift protokollü birimler kullanılırken ve SMB istemcilerinden verilere erişilirken aşağıdaki davranışlar gözlemlenebilir.
- Düzgün erişim denetimi çözümlemesi için Windows kullanıcı adlarının UNIX kullanıcı adlarıyla düzgün eşlenmesi gerekir.
- UNIX güvenlik stili birimlerinde (NFSv4.x ACL'lerinin uygulanacağı) bir Windows kullanıcısının LDAP sunucusunda geçerli bir UNIX kullanıcısı yoksa eşleme için (uid sayısal 65534 ile) adlı
pcuservarsayılan bir UNIX kullanıcısı kullanılır. - Geçerli UNIX kullanıcı eşlemesi olmayan Windows kullanıcılarıyla yazılan dosyalar, NFS bağlamalarından Linux istemcilerinde "nfsnobody" veya "kimse" kullanıcı adlarına karşılık gelen sayısal kimlik 65534'e ait olarak görüntülenir. Bu, genellikle NFSv4.x kimliği etki alanı sorunlarında görülen sayısal kimlik 99'dan farklıdır. Kullanılan sayısal kimliği doğrulamak için komutunu kullanın
ls -lan. - Yanlış sahiplere sahip dosyalar UNIX modu bitlerinden veya NFSv4.x ACL'lerinden beklenen sonuçları sağlamaz.
- NFSv4.x ACL'leri NFS istemcilerinden yönetilir. SMB istemcileri NFSv4.x ACL'lerini görüntüleyemez veya yönetemez.
NFSv4.x ACL'leri ile Umask etkisi
NFSv4 ACL'leri ACL devralma olanağı sağlar. ACL devralma, NFSv4 ACL'leri ayarlanmış nesnelerin altında oluşturulan dosya veya klasörlerin ACL devralma bayrağının yapılandırmasına göre ACL'leri devralabileceği anlamına gelir.
Umask, dizinde dosya ve klasörlerin oluşturulduğu izin düzeyini denetlemek için kullanılır. Varsayılan olarak, Azure NetApp Files umask'ın devralınan ACL'leri geçersiz kılmasına izin verir. Bu, RFC-7530'a göre beklenen davranıştır.
Daha fazla bilgi için bkz . umask.
NFSv4.x ACL'leri ile Chmod/chown davranışı
Azure NetApp Files'da, NFSv3 ve NFSv4.x üzerindeki dosya ve dizin izinlerini yönetmek için değişiklik sahipliği (chown) ve değişiklik modu biti (chmod) komutlarını kullanabilirsiniz.
NFSv4.x ACL'leri kullanılırken, dosyalara ve klasöre uygulanan daha ayrıntılı denetimler chmod komutlarına olan ihtiyacı azaltıyor. Chown'un hala bir yeri var, çünkü NFSv4.x ACL'leri sahipliği atamıyor.
Chmod, NFSv4.x ACL'lerinin uygulandığı dosya ve klasörlerde Azure NetApp Files'da çalıştırıldığında, nesne üzerinde mod bitleri değiştirilir. Ayrıca, bu mod bitlerini yansıtacak şekilde bir dizi sistem ACL'si değiştirilir. Sistem ACL'leri kaldırılırsa mod bitleri temizlenir. Örnekler ve daha eksiksiz bir açıklama aşağıdaki sistem ACL'leri bölümünde bulunabilir.
Chown Azure NetApp Files'da çalıştırıldığında, atanan sahip değiştirilebilir. NFSv4.x ACL'leri kullanılırken dosya sahipliği, mod bitleri kullanılırken olduğu kadar kritik değildir; çünkü ACL'ler temel sahip/grup/herkes kavramlarının yapamadığı yollarla izinleri denetlemek için kullanılabilir. Dışarı aktarma denetimleri yalnızca kökün sahiplik değişiklikleri yapmasına izin verecek şekilde yapılandırıldığından Azure NetApp Files'da Chown yalnızca kök olarak (kök olarak veya sudo kullanılarak) çalıştırılabilir. Bu, Azure NetApp Files'da varsayılan dışarı aktarma ilkesi kuralı tarafından denetlendiğinden, sahiplik değişikliklerine izin veren NFSv4.x ACL girişleri uygulanmaz.
# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r-- 1 user1 root 0 Jul 12 16:23 testdir
Birimdeki dışarı aktarma ilkesi kuralı, bu davranışı değiştirmek için değiştirilebilir. Birimin dışarı aktarma ilkesi menüsünde Chown modunu "kısıtlanmamış" olarak değiştirin.
Değiştirildikten sonra sahiplik, uygun erişim haklarına sahip olan kök dışındaki kullanıcılar tarafından değiştirilebilir. Bunun için "Sahipliği Al" NFSv4.x ACL izni ("o" harfiyle belirlenir) gerekir. Sahipliği değiştiren kullanıcı şu anda dosya veya klasöre sahipse sahiplik de değiştirilebilir.
A::user1@contoso.com:rwatTnNcCy << no ownership flag (o)
user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied
A::user1@contoso.com:rwatTnNcCoy << with ownership flag (o)
user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root 4096 Jul 14 16:31 .
drwxrwxrwx 5 root root 4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root 0 Jul 14 15:45 newfile
-rw-r--r-- 1 root root 0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294 0 Jul 14 16:31 newfile3
Sistem ACL'leri
Her ACL'de bir dizi sistem ACL'si vardır: OWNER@, GROUP@, EVERYONE@. Örneğin:
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy
Bu ACL'ler, NFSv3'te görebileceğiniz klasik mod bit izinleri ile karşılık gelir ve bu izinlerle doğrudan ilişkilendirilir. Bir nesne üzerinde bir chmod çalıştırıldığında, bu sistem ACL'leri bu izinleri yansıtacak şekilde değişir.
# nfs4_getfacl user1-file
# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy
# chmod 755 user1-file
# nfs4_getfacl user1-file
# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy
Bu sistem ACL'leri kaldırılırsa, izin görünümü normal mod bitlerinin (rwx) tire olarak görünmesi için değişir.
# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
---------- 1 user1 group1 0 Jul 12 16:23 user1-file
Yalnızca ACL'de (ve kök) kullanıcı ve grup sorumluları nesneye erişebildiği için sistem ACE'lerini kaldırmak, dosya ve klasörlerin güvenliğini sağlamanın bir yoludur. Sistem ACL'lerinin kaldırılması, işlevsellik için mod bit görünümlerini kullanan uygulamaları bozabilir.
NFSv4.x ACL'leri ile kök kullanıcı davranışı
Kök sıkıştırılmadıkça NFSv4.x ACL'leri ile kök erişimi sınırlanamaz. Kök sıkıştırma, erişimi sınırlamak için kökün anonim bir kullanıcıyla eşlendiği dışarı aktarma ilkesi kuralının yapılandırıldığı yerdir. Kök erişim, kök erişim ilke kuralı kapalı olarak değiştirilerek bir birimin Dışarı aktarma ilkesi menüsünden yapılandırılabilir.
Kök sıkıştırmayı yapılandırmak için, birimdeki İlkeyi dışarı aktar menüsüne gidin ve ilke kuralı için "Kök erişim"i "kapalı" olarak değiştirin.
Kök erişim kökünü devre dışı bırakmanın etkisi anonim kullanıcıya nfsnobody:65534ezilir. Kök erişim daha sonra sahipliği değiştiremiyor.
root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2 root 4096 Jul 14 16:31 .
drwxrwxrwx 5 root root 4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root 0 Jul 14 15:45 newfile
-rw-r--r-- 1 root root 0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294 0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2 1002 0 4096 Jul 14 16:31 .
drwxrwxrwx 5 0 0 4096 Jul 13 13:46 ..
-rw-r--r-- 1 1001 0 0 Jul 14 15:45 newfile
-rw-r--r-- 1 0 0 0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294 0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted
Alternatif olarak, çift protokollü ortamlarda, kök erişimi ayrıntılı olarak sınırlamak için NTFS ACL'leri kullanılabilir.
Sonraki adımlar
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin