Omówienie list kontroli dostępu NFSv4.x w usłudze Azure NetApp Files
Protokół NFSv4.x może zapewnić kontrolę dostępu w postaci list kontroli dostępu (ACL), które są koncepcyjnie podobne do list ACL używanych w protokole SMB za pośrednictwem uprawnień systemu plików NTFS systemu Windows. Lista ACL NFSv4.x składa się z pojedynczych wpisów kontroli dostępu (ACL), z których każda zapewnia dyrektywę kontroli dostępu do serwera.
Każda lista ACL NFSv4.x jest tworzona w formacie type:flags:principal:permissions.
- Type — typ zdefiniowanej listy ACL. Prawidłowe opcje obejmują dostęp (A), odmów (D), Inspekcja (U), Alarm (L). Usługa Azure NetApp Files obsługuje typy listy ACL dostępu, odmowy i inspekcji, ale inspekcja list ACL, podczas gdy można je ustawić, nie generują obecnie dzienników inspekcji.
- Flagi — dodaje dodatkowy kontekst listy ACL. Istnieją trzy rodzaje flag ACE: grupa, dziedziczenie i administracja. Aby uzyskać więcej informacji na temat flag, zobacz flagi NFSv4.x ACE.
- Principal — definiuje użytkownika lub grupę, która jest przypisana do listy ACL. Podmiot zabezpieczeń na NFSv4.x ACL używa formatu name@ID-DOMAIN-STRING.COM. Aby uzyskać bardziej szczegółowe informacje na temat podmiotów zabezpieczeń, zobacz NFSv4.x user and group principals (Podmioty zabezpieczeń i grupy NFSv4.x).
- Uprawnienia — gdzie zdefiniowano poziom dostępu dla podmiotu zabezpieczeń. Każde uprawnienie jest wyznaczone pojedynczą literą (na przykład odczyt pobiera "r", zapis pobiera "w" itd.). Pełny dostęp będzie zawierał każdy dostępny list uprawnień. Aby uzyskać więcej informacji, zobacz uprawnienia NFSv4.x.
A:g:group1@contoso.com:rwatTnNcCy jest przykładem prawidłowej listy ACL, zgodnie z formatem type:flags:principal:permissions . Przykładowa lista ACL udziela pełnego dostępu do grupy group1 w domenie contoso.com ID.
Flagi NFSv4.x ACE
Flaga ACE pomaga podać więcej informacji na temat ACE w liście ACL. Na przykład jeśli grupa ACE jest dodawana do listy ACL, flaga grupy musi być używana do wyznaczenia podmiotu zabezpieczeń jest grupą, a nie użytkownikiem. W środowiskach systemu Linux można mieć użytkownika i nazwę grupy, która jest identyczna, więc flaga zapewnia honorowanie ACE, a następnie serwer NFS musi wiedzieć, jaki typ podmiotu zabezpieczeń jest definiowany.
Inne flagi mogą służyć do kontrolowania ACL, takich jak dziedziczenie i flagi administracyjne.
Flagi dostępu i odmowy
Flagi dostępu (A) i odmowy (D) służą do kontrolowania typów ACE zabezpieczeń. Usługa ACE dostępu kontroluje poziom uprawnień dostępu w pliku lub folderze podmiotu zabezpieczeń. Odmowa ACE jawnie zabrania podmiotowi zabezpieczeń uzyskiwania dostępu do pliku lub folderu, nawet jeśli ustawiono dostęp do ACE, który zezwoliłby temu podmiotowi zabezpieczeń na dostęp do obiektu. Odmowa kontroli dostępu zawsze unieważnia dostęp ACL. Ogólnie rzecz biorąc, należy unikać używania odmów kontroli dostępu, ponieważ listy ACL NFSv4.x są zgodne z modelem "odmowy domyślnej", co oznacza, że jeśli lista ACL nie zostanie dodana, odmowa jest niejawna. Odmowa kontroli dostępu może powodować niepotrzebne komplikacje w zarządzaniu listami ACL.
Flagi dziedziczenia
Flagi dziedziczenia kontrolują zachowanie list ACL dla plików utworzonych poniżej katalogu nadrzędnego z ustawionym flagą dziedziczenia. Po ustawieniu flagi dziedziczenia pliki i/lub katalogi dziedziczą listy ACL z folderu nadrzędnego. Flagi dziedziczenia można stosować tylko do katalogów, więc po utworzeniu podkatalogu dziedziczy flagę. Pliki utworzone poniżej katalogu nadrzędnego z flagą dziedziczenia dziedziczą listy ACL, ale nie flag dziedziczenia.
W poniższej tabeli opisano dostępne flagi dziedziczenia i ich zachowania.
| Flaga dziedziczenia | Zachowanie |
|---|---|
| d | - Katalogi poniżej katalogu nadrzędnego dziedziczą listę ACL - Flaga dziedziczenia jest również dziedziczona |
| f | — Pliki poniżej katalogu nadrzędnego dziedziczą listę ACL — Pliki nie ustawiają flagi dziedziczenia |
| i | Tylko dziedziczone; Lista ACL nie ma zastosowania do bieżącego katalogu, ale musi stosować dziedziczenie do obiektów poniżej katalogu |
| n | - Brak propagacji dziedziczenia Po dziedziczeniu listy ACL flagi dziedziczone są wyczyszczone na obiektach znajdujących się poniżej obiektu nadrzędnego |
Przykłady listy ACL NFSv4.x
W poniższym przykładzie istnieją trzy różne acEs z odrębnymi flagami dziedziczenia:
- katalog dziedziczy tylko (di)
- plik dziedziczy tylko (fi)
- zarówno plik, jak i katalog dziedziczy (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 katalog dziedziczy tylko listę ACL. W podkatalogu utworzonym poniżej elementu nadrzędnego lista ACL jest dziedziczona, ale w pliku poniżej elementu nadrzędnego nie jest.
# 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 ma flagę dziedziczenia pliku i katalogu. W związku z tym zarówno pliki, jak i katalogi poniżej katalogu z tym wpisem ACE dziedziczą listę ACL, ale pliki nie dziedziczą flagi.
# 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 Ma tylko flagę dziedziczenia pliku. W związku z tym tylko pliki poniżej katalogu z tym wpisem ACE dziedziczą listę ACL, ale nie dziedziczą flagi, ponieważ mogą być stosowane tylko do katalogów ACE.
# 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
Gdy flaga "no-propagate" (n) jest ustawiona na listy ACL, flagi są czyszczane dla kolejnych tworzenia katalogów poniżej elementu nadrzędnego. W poniższym przykładzie user2 ustawiono flagę n . W związku z tym podkatalog czyści flagi dziedziczone dla tego podmiotu zabezpieczeń i obiektów utworzonych poniżej tego podkatalogu nie dziedziczą ACE z user2.
# 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
Flagi dziedziczone są sposobem łatwiejszego zarządzania listami ACL NFSv4.x, co pozwala jawnie ustawiać listę ACL za każdym razem, gdy jest potrzebny.
Flagi administracyjne
Flagi administracyjne w listach ACL systemu plików NFSv4.x to specjalne flagi, które są używane tylko z typami listy ACL inspekcji i alarmów. Te flagi definiują próby dostępu zakończone powodzeniem (S) lub niepowodzeniem (F) dla akcji do wykonania.
Usługa Azure NetApp Files obsługuje ustawianie flag administracyjnych dla kontroli kontroli dostępu, jednak ACL nie działają. Ponadto usługi Alarm ACEs nie są obsługiwane w usłudze Azure NetApp Files.
NFSv4.x użytkowników i podmiotów zabezpieczeń grupy
W przypadku list ACL NFSv4.x podmioty zabezpieczeń użytkowników i grup definiują określone obiekty, do których należy zastosować ACE. Podmioty zabezpieczeń zazwyczaj mają format name@ID-DOMAIN-STRING.COM. Część "name" podmiotu zabezpieczeń może być użytkownikiem lub grupą, ale ten użytkownik lub grupa musi być rozpoznawany w usłudze Azure NetApp Files za pośrednictwem połączenia serwera LDAP podczas określania domeny identyfikatora NFSv4.x. Jeśli name@domain nie jest rozpoznawana przez usługę Azure NetApp Files, operacja listy ACL kończy się niepowodzeniem z powodu błędu "nieprawidłowy argument".
# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument
Możesz sprawdzić w usłudze Azure NetApp Files, czy można rozpoznać nazwę przy użyciu listy identyfikatorów grupy LDAP. Przejdź do pozycji Pomoc techniczna i rozwiązywanie problemów, a następnie wybierz listę identyfikatorów grupy LDAP.
Dostęp użytkowników lokalnych i grup za pośrednictwem list ACL NFSv4.x
Lokalni użytkownicy i grupy mogą być również używane na liście ACL NFSv4.x, jeśli w liście ACL określono tylko identyfikator liczbowy. Nazwy użytkowników lub identyfikatory liczbowe z określonym identyfikatorem domeny kończą się niepowodzeniem.
Przykład:
# 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
Po ustawieniu listy ACL użytkownika lokalnego lub grupy dowolny użytkownik lub grupa odpowiadająca identyfikatorowi liczbowemu na liście ACL odbiera dostęp do obiektu. W przypadku list ACL grup lokalnych użytkownik przekazuje członkostw w grupach do usługi Azure NetApp Files. Jeśli identyfikator liczbowy grupy z dostępem do pliku za pośrednictwem żądania użytkownika jest wyświetlany na serwerze NFS usługi Azure NetApp Files, dostęp jest dozwolony zgodnie z listą ACL.
Poświadczenia przekazywane z klienta do serwera można zobaczyć za pośrednictwem przechwytywania pakietów, jak pokazano poniżej.
Zastrzeżenia:
- Używanie lokalnych użytkowników i grup dla list ACL oznacza, że każdy klient, który uzyskuje dostęp do plików/folderów, musi mieć zgodne identyfikatory użytkowników i grup.
- W przypadku używania identyfikatora liczbowego dla listy ACL usługa Azure NetApp Files niejawnie ufa, że przychodzące żądanie jest prawidłowe i że użytkownik żądający dostępu jest tym, kim są i jest członkiem grup, do których twierdzi, że jest członkiem. Jeśli nieprawidłowy aktor zna identyfikator liczbowy użytkownika lub grupę, może uzyskać dostęp do sieci przy użyciu klienta z możliwością tworzenia użytkowników i grup lokalnie.
- Jeśli użytkownik jest członkiem więcej niż 16 grup, każda grupa po szesnastej grupie (w kolejności alfanumerycznej) nie będzie mieć dostępu do pliku lub folderu, chyba że jest używana obsługa protokołu LDAP i rozszerzonej grupy.
- W przypadku korzystania z list ACL NFSv4.x w celu zapewnienia lepszej możliwości zarządzania i zabezpieczeń zdecydowanie zaleca się używanie list ACL ldap i pełnych name@domain nazw. Centralnie zarządzane repozytorium użytkowników i grup jest łatwiejsze do obsługi i trudniejsze do fałszowania, co sprawia, że niepożądany dostęp użytkowników jest mniej prawdopodobny.
Domena identyfikatora NFSv4.x
Domena identyfikatora jest ważnym składnikiem podmiotu zabezpieczeń, w którym domena identyfikatora musi być zgodna zarówno na kliencie, jak i w usłudze Azure NetApp Files dla nazw użytkowników i grup (w szczególności katalogu głównego), aby prawidłowo wyświetlać się na własnościach plików/folderów.
Usługa Azure NetApp Files domyślnie określa domenę identyfikatora NFSv4.x w ustawieniach domeny DNS dla woluminu. Klienci systemu plików NFS również domyślnie do domeny DNS dla domeny NFSv4.x id. Jeśli domena DNS klienta różni się od domeny DNS usługi Azure NetApp Files, występuje niezgodność. Podczas wyświetlania listy uprawnień do pliku za pomocą poleceń, takich jak ls, użytkownicy/grupy są wyświetlane jako "nikt".
W przypadku niezgodności domeny między klientem NFS i usługą Azure NetApp Files sprawdź dzienniki klienta pod kątem błędów podobnych do:
August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'
Domena identyfikatora klienta systemu plików NFS może zostać zastąpiona przy użyciu ustawienia "Domena" pliku /etc/idmapd.conf. Na przykład: Domain = CONTOSO.COM.
Usługa Azure NetApp Files umożliwia również zmianę domeny identyfikatora NFSv4.1. Aby uzyskać dodatkowe informacje, zobacz Instrukcje: konfiguracja domeny identyfikatora NFSv4.1 dla usługi Azure NetApp Files.
Uprawnienia NFSv4.x
Uprawnienia NFSv4.x to sposób kontrolowania poziomu dostępu do określonego użytkownika lub jednostki grupy w pliku lub folderze. Uprawnienia w systemie plików NFSv3 zezwalają tylko na poziomy odczytu/zapisu/wykonywania (rwx) definicji dostępu, ale NFSv4.x zapewnia mnóstwo innych szczegółowych kontroli dostępu jako ulepszenie bitów trybu NFSv3.
Istnieje 13 uprawnień, które można ustawić dla użytkowników i 14 uprawnień, które można ustawić dla grup.
| List uprawnień | Udzielono uprawnień |
|---|---|
| r | Odczytywanie plików i folderów danych/list |
| w | Zapisywanie danych/tworzenie plików i folderów |
| a | Dołączanie danych/tworzenie podkatalogów |
| x | Wykonywanie plików/przechodzenie do katalogów |
| d | Usuwanie plików/katalogów |
| D | Usuwanie podkatalogów (tylko katalogi) |
| t | Atrybuty odczytu (GETATTR) |
| T | Atrybuty zapisu (SETATTR/chmod) |
| n | Odczytywanie nazwanych atrybutów |
| N | Zapisywanie nazwanych atrybutów |
| c | Odczyt list ACL |
| C | Zapisywanie list ACL |
| o | Właściciel zapisu (suknia) |
| t | Synchroniczne operacje we/wy |
Po ustawieniu uprawnień dostępu użytkownik lub podmiot zabezpieczeń grupy jest zgodny z tymi przypisanymi prawami.
Przykłady uprawnień NFSv4.x
W poniższych przykładach pokazano, jak różne uprawnienia działają w różnych scenariuszach konfiguracji.
Użytkownik z dostępem do odczytu (tylko r)
W przypadku dostępu tylko do odczytu użytkownik może odczytywać atrybuty i dane, ale odmowa dostępu do zapisu (danych, atrybutów, właściciela).
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
Użytkownik z dostępem do odczytu (r) i atrybutami zapisu (T)
W tym przykładzie uprawnienia do pliku można zmienić z powodu uprawnień atrybutów zapisu (T), ale nie można utworzyć żadnych plików, ponieważ dozwolony jest tylko dostęp do odczytu. Ta konfiguracja ilustruje rodzaj szczegółowych kontrolek NFSv4.x list ACL może zapewnić.
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
Tłumaczenie bitów trybu na uprawnienia listy ACL NFSv4.x
Gdy chmod jest uruchamiany obiekt z przypisanymi listami ACL NFSv4.x, serię list ACL systemu są aktualizowane z nowymi uprawnieniami. Jeśli na przykład uprawnienia są ustawione na 755, pliki listy ACL systemu są aktualizowane. W poniższej tabeli przedstawiono, na co każda wartość liczbowa w trybie bitowym przekłada się na uprawnienia listy ACL NFSv4.
Zobacz uprawnienia NFSv4.x, aby zapoznać się z tabelą przedstawiającą wszystkie uprawnienia.
| Tryb liczbowy bitowy | Odpowiednie uprawnienia NFSv4.x |
|---|---|
| 1 — wykonywanie (x) | Wykonywanie, odczytywanie atrybutów, odczytywanie list ACL, synchronizowanie operacji we/wy (xtcy) |
| 2 — zapis (w) | Zapisywanie, dołączanie danych, atrybuty odczytu, atrybuty zapisu, zapisywanie nazwanych atrybutów, listy ACL odczytu, operacje we/wy synchronizacji (watTNcy) |
| 3 — zapis/wykonanie (wx) | Zapisywanie, dołączanie danych, wykonywanie, odczytywanie atrybutów, atrybuty zapisu, zapisywanie nazwanych atrybutów, listy ACL odczytu, operacje we/wy synchronizacji (waxtTNcy) |
| 4 — odczyt (r) | Odczytywanie, odczytywanie atrybutów, odczytywanie nazwanych atrybutów, odczytywanie list ACL, synchronizowanie operacji we/wy (rtncy) |
| 5 — odczyt/wykonanie (rx) | Odczyt, wykonywanie, odczytywanie atrybutów, odczytywanie nazwanych atrybutów, odczytywanie list ACL, synchronizacja we/wy (rxtncy) |
| 6 — odczyt/zapis (rw) | Odczyt, zapis, dołączanie danych, atrybuty odczytu, atrybuty zapisu, atrybuty nazwane odczytu, zapis nazwanych atrybutów, listy ACL odczytu, synchronizacja we/wy (rwatTnNcy) |
| 7 — odczyt/zapis/wykonanie (rwx) | Pełna kontrola/wszystkie uprawnienia |
Jak listy ACL NFSv4.x działają z usługą Azure NetApp Files
Usługa Azure NetApp Files obsługuje natywnie listy ACL NFSv4.x, gdy wolumin ma włączony dostęp do woluminu NFSv4.1. Nie ma nic do włączenia na woluminie na potrzeby obsługi listy ACL, ale aby listy ACL NFSv4.1 działały najlepiej, serwer LDAP z użytkownikami i grupami systemu UNIX jest potrzebny, aby zapewnić, że usługa Azure NetApp Files będzie mogła bezpiecznie rozpoznać podmioty zabezpieczeń ustawione na listach ACL. Użytkownicy lokalni mogą służyć z listami ACL NFSv4.x, ale nie zapewniają tego samego poziomu zabezpieczeń co listy ACL używane z serwerem LDAP.
Należy pamiętać o funkcjach listy ACL w usłudze Azure NetApp Files.
Dziedziczenie listy ACL
W usłudze Azure NetApp Files flagi dziedziczenia listy ACL mogą służyć do uproszczenia zarządzania listami ACL z listami ACL NFSv4.x. Po ustawieniu flagi dziedziczenia listy ACL w katalogu nadrzędnym mogą być propagowane do podkatalogów i plików bez dalszej interakcji. Usługa Azure NetApp Files implementuje standardowe zachowania dziedziczone przez listę ACL zgodnie z specyfikacją RFC-7530.
Odmowa kontroli dostępu
Odmowa kontroli dostępu w usłudze Azure NetApp Files służy do jawnego ograniczenia dostępu użytkownika lub grupy do pliku lub folderu. Podzbiór uprawnień można zdefiniować w celu zapewnienia szczegółowych kontroli nad odmową ACE. Działają one w standardowych metodach wymienionych w RFC-7530.
Zachowywanie listy ACL
Gdy moduł chmod jest wykonywany w pliku lub folderze w usłudze Azure NetApp Files, wszystkie istniejące elementy ACL są zachowywane na liście ACL innej niż systemowe acEs (OWNER@, GROUP@, EVERYONE@). Te uprawnienia ACE są modyfikowane zgodnie z definicją przez bity trybu liczbowego zdefiniowane przez polecenie chmod. Można zmienić tylko elementy ACE, które są ręcznie modyfikowane lub usuwane za pomocą nfs4_setfacl polecenia.
Zachowania listy ACL NFSv4.x w środowiskach z podwójnym protokołem
Protokół podwójny odnosi się do użycia zarówno protokołu SMB, jak i NFS w tym samym woluminie usługi Azure NetApp Files. Mechanizmy kontroli dostępu za pomocą dwóch protokołów są określane przez styl zabezpieczeń używany przez wolumin, ale mapowanie nazwy użytkownika zapewnia, że użytkownicy systemu Windows i użytkownicy systemu UNIX, którzy pomyślnie mapują się na siebie, mają takie same uprawnienia dostępu do danych.
Gdy listy ACL NFSv4.x są używane w woluminach stylu zabezpieczeń systemu UNIX, podczas korzystania z woluminów z dwoma protokołami i uzyskiwania dostępu do danych z klientów SMB można zaobserwować następujące zachowania.
- Nazwy użytkowników systemu Windows muszą być prawidłowo mapowane na nazwy użytkowników systemu UNIX w celu zapewnienia prawidłowego rozpoznawania kontroli dostępu.
- W woluminach w stylu zabezpieczeń systemu UNIX (gdzie mają być stosowane listy ACL systemu NFSv4.x), jeśli na serwerze LDAP nie istnieje prawidłowy użytkownik SYSTEMU UNIX, do mapowania jest używany domyślny użytkownik systemu UNIX o nazwie
pcuser(z numerem uid 65534). - Pliki zapisane dla użytkowników systemu Windows bez prawidłowego mapowania użytkownika systemu UNIX są wyświetlane jako należące do numerycznego identyfikatora 65534, który odpowiada "nfsnobody" lub "nikt" nazwy użytkowników w klientach systemu Linux z instalacji NFS. Różni się to od identyfikatora liczbowego 99, który zwykle występuje w przypadku problemów z domeną identyfikatora NFSv4.x. Aby zweryfikować używany identyfikator liczbowy, użyj
ls -lanpolecenia . - Pliki z nieprawidłowymi właścicielami nie zapewniają oczekiwanych wyników z bitów trybu UNIX ani z list ACL trybu NFSv4.x.
- Listy ACL NFSv4.x są zarządzane z klientów NFS. Klienci SMB nie mogą wyświetlać list ACL NFSv4.x ani zarządzać nimi.
Wpływ maski Umask z listami ACL NFSv4.x
Listy ACL NFSv4 zapewniają możliwość oferowania dziedziczenia listy ACL. Dziedziczenie listy ACL oznacza, że pliki lub foldery utworzone pod obiektami z zestawem ACL NFSv4 mogą dziedziczyć listy ACL na podstawie konfiguracji flagi dziedziczenia listy ACL.
Maska Umask służy do kontrolowania poziomu uprawnień, na którym pliki i foldery są tworzone w katalogu. Domyślnie usługa Azure NetApp Files umożliwia maskowanie przesłonięć dziedziczone listy ACL, co jest oczekiwane zachowanie zgodnie z RFC-7530.
Aby uzyskać więcej informacji, zobacz maska umask.
Zachowanie chmod/chown z listami ACL NFSv4.x
W usłudze Azure NetApp Files można użyć poleceń zmiany własności (chown) i bitów trybu zmiany (chmod), aby zarządzać uprawnieniami do plików i katalogów w systemach NFSv3 i NFSv4.x.
W przypadku korzystania z list ACL NFSv4.x bardziej szczegółowe kontrolki stosowane do plików i folderów zmniejsza potrzebę poleceń chmod. Chown nadal ma miejsce, ponieważ listy ACL NFSv4.x nie przypisują własności.
Gdy tryb chmod jest uruchamiany w usłudze Azure NetApp Files w plikach i folderach z zastosowanymi listami ACL systemu plików NFSv4.x, bity trybu są zmieniane w obiekcie. Ponadto zestaw systemowych ACL jest modyfikowany w celu odzwierciedlenia tych bitów trybu. Jeśli system acEs zostanie usunięty, bity trybu zostaną wyczyszczone. Przykłady i bardziej pełny opis można znaleźć w sekcji dotyczącej systemów kontroli dostępu poniżej.
Po uruchomieniu elementu own w usłudze Azure NetApp Files można zmodyfikować przypisanego właściciela. Własność plików nie jest tak krytyczna w przypadku korzystania z list ACL NFSv4.x, jak w przypadku korzystania z bitów trybu, ponieważ listy ACL mogą służyć do kontrolowania uprawnień w sposób, w jaki nie można kontrolować podstawowych pojęć właściciela/grupy/wszystkich. Narzędzie Chown w usłudze Azure NetApp Files może być uruchamiane tylko jako katalog główny (jako katalog główny lub za pomocą polecenia sudo), ponieważ kontrolki eksportu są skonfigurowane tak, aby zezwalały tylko katalogowi głównemu na wprowadzanie zmian własności. Ponieważ jest to kontrolowane przez domyślną regułę zasad eksportu w usłudze Azure NetApp Files, wpisy listy ACL NFSv4.x, które zezwalają na modyfikacje własności, nie mają zastosowania.
# 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
Reguła zasad eksportu na woluminie może zostać zmodyfikowana, aby zmienić to zachowanie. W menu Eksportuj zasady dla woluminu zmodyfikuj tryb Chown tak, aby był "nieograniczony".
Po zmodyfikowaniu własność może zostać zmieniona przez użytkowników innych niż root, jeśli mają odpowiednie prawa dostępu. Wymaga to uprawnienia listy ACL NFSv4.x (wyznaczonej przez literę "o"). Własność można również zmienić, jeśli użytkownik zmieniający własność jest obecnie właścicielem pliku lub folderu.
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
Systemowe aces
Na każdej listach ACL istnieje szereg systemów ACL: OWNER@, GROUP@, EVERYONE@. Na przykład:
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy
Te ACL odpowiadają uprawnieniam bitów trybu klasycznego widocznym w systemie plików NFSv3 i są bezpośrednio skojarzone z tymi uprawnieniami. Gdy moduł chmod jest uruchamiany w obiekcie, te listy ACL systemu zmieniają się w celu odzwierciedlenia tych uprawnień.
# 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
Jeśli te systemowe acE zostaną usunięte, widok uprawnień zmieni się tak, aby bity trybu normalnego (rwx) były wyświetlane jako kreski.
# 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
Usuwanie systemowych ACL to sposób na dalsze zabezpieczanie plików i folderów, ponieważ tylko podmioty zabezpieczeń użytkowników i grup na liście ACL (i katalogu głównym) mogą uzyskiwać dostęp do obiektu. Usunięcie systemowych kontroli dostępu użytkowników może przerwać aplikacje, które opierają się na widokach bitów trybu na potrzeby funkcji.
Zachowanie użytkownika głównego z listami ACL NFSv4.x
Dostęp do katalogu głównego z listami ACL NFSv4.x nie może być ograniczony, chyba że katalog główny zostanie zgnieciony. Root squashing to miejsce, w którym skonfigurowano regułę zasad eksportu, w której katalog główny jest mapowany na anonimowego użytkownika w celu ograniczenia dostępu. Dostęp główny można skonfigurować z menu zasad eksportu woluminu, zmieniając regułę zasad dostępu root na wyłączone.
Aby skonfigurować usuwanie katalogu głównego, przejdź do menu Eksportuj zasady na woluminie, a następnie zmień wartość "Dostęp główny" na "wyłączone" dla reguły zasad.
Efekt wyłączania root access root squashes do anonimowego użytkownika nfsnobody:65534. Dostęp do katalogu głównego nie może zmienić własności.
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
Alternatywnie w środowiskach z podwójnym protokołem listy ACL systemu plików NTFS mogą służyć do szczegółowego ograniczania dostępu do katalogu głównego.