Udostępnij za pośrednictwem

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 poszczególnych wpisów kontroli dostępu (ACE), z których każdy zawiera dyrektywę kontroli dostępu do serwera.

Diagram jednostki kontroli dostępu do usługi Azure NetApp Files.

Każda lista kontroli dostępu (ACL) NFSv4.x jest tworzona w formacie type:flags:principal:permissions.

  • Type – typ definiowanej listy ACL. Prawidłowe opcje obejmują Dostęp (A), Odmowa (D), Audyt (U), Alarm (L). Usługa Azure NetApp Files obsługuje typy list ACL dostępu, odmowy i inspekcji, ale listy inspekcji ACL, mimo że można je ustawić, nie generują obecnie dzienników inspekcji.
  • Flagi — dodają dodatkowy kontekst dla listy kontroli dostępu. Istnieją trzy rodzaje flag ACE: grupa, dziedziczenie i administracja. Aby uzyskać więcej informacji na temat flag, zobacz flagi ACE NFSv4.x.
  • Principal — definiuje użytkownika lub grupę, która jest przypisana do listy ACL. Podmiot na NFSv4.x ACL używa formatu name@ID-DOMAIN-STRING.COM. Aby uzyskać bardziej szczegółowe informacje na temat użytkowników i grup głównych, zobacz Podmioty użytkowników i grup NFSv4.x.
  • Uprawnienia — gdzie zdefiniowano poziom dostępu dla głównego odbiorcy. Każde uprawnienie jest oznaczone pojedynczą literą (na przykład odczyt otrzymuje "r", zapis otrzymuje "w" itd.). Pełny dostęp będzie obejmował każde dostępne pozwolenie. 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 może dostarczać więcej informacji na temat ACE w liście ACL. Na przykład, jeśli grupa ACE jest dodawana do listy ACL, należy użyć flagi grupy, aby wskazać, że dany podmiot 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 ACE, na przykład dziedziczenie i flagi administracyjne.

Flagi dostępu i odmowy

Flagi dostępu (A) i odmowy (D) służą do kontrolowania typów ACE zabezpieczeń. ACE dostępu kontroluje poziom uprawnień dostępu do pliku lub folderu dla podmiotu. 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. Odmowne ACE zawsze mają pierwszeństwo przed ACE dostępu. Ogólnie rzecz biorąc, należy unikać używania odmów ACE, ponieważ ACL NFSv4.x działają w modelu "domyślnej odmowy", co oznacza, że jeśli 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ą, jak zachowują się listy ACL dla plików utworzonych w podrzędnych katalogach z ustawioną 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 w katalogu nadrzędnym z flagą dziedziczenia dziedziczą listy kontroli dostępu (ACL), ale nie flagi dziedziczenia.

W poniższej tabeli opisano dostępne flagi dziedziczenia i ich zachowania.

Flaga dziedziczenia Zachowanie
d - Katalogi znajdujące się poniżej katalogu nadrzędnego dziedziczą ustawienia ACL
- Flaga dziedziczenia jest również przekazywana
f — Pliki poniżej katalogu nadrzędnego dziedziczą Listę Kontroli Dostępu (ACL)
— Pliki nie ustawiają flagi dziedziczenia
ja Tylko dziedziczone; ACL nie ma zastosowania do bieżącego katalogu, ale musi stosować dziedziczenie na obiekty 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 ACL w 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 dziedziczą (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 ma tylko dziedziczoną listę ACL. W podkatalogu utworzonym pod głównym katalogiem, ACL jest dziedziczona, ale w pliku poniżej elementu nadrzędnego już nie.

# 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 rezultacie zarówno pliki, jak i katalogi znajdujące się poniżej katalogu z 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 posiada 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ż można ją stosować tylko do katalogów z wpisami 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 liście kontroli dostępu (ACL), flagi są czyszczone podczas tworzenia kolejnych katalogów poniżej elementu nadrzędnego. W poniższym przykładzie user2 ma ustawioną flagę n. W związku z tym podkatalog czyści flagi dziedziczenia dla tego podmiotu zabezpieczeń, a obiekty utworzone 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 dziedziczenia ułatwiają zarządzanie listami ACL dla NFSv4.x, oszczędzając konieczność ustawiania listy ACL za każdym razem, gdy jest potrzebna.

Flagi administracyjne

Flagi administracyjne w listach ACL NFSv4.x to specjalne flagi, które są używane wyłącznie z typami ACL do audytu i alarmów. Te flagi określają, czy próby dostępu do wykonania akcji zakończą się sukcesem (S) czy niepowodzeniem (F).

Ta lista kontroli dostępu jest przykładem tego, gdzie user1 jest poddawane inspekcji pod kątem nieudanych prób dostępu dla dowolnego poziomu uprawnień: U:F:user1@contoso.com:rwatTnNcCy.

Usługa Azure NetApp Files obsługuje tylko ustawianie flag administracyjnych dla Audit ACEs, jednak ACE nie działają. Usługi ACE alarmów nie są obsługiwane w usłudze Azure NetApp Files.

Zasady użytkowników i grup NFSv4.x

W przypadku list ACL NFSv4.x zasady zabezpieczeń użytkowników i grup określają obiekty docelowe, których dotyczy ACE. Dyrektorzy zazwyczaj stosują format name@ID-DOMAIN-STRING.COM. Część "nazwa" podmiotu może być użytkownikiem lub grupą, ale ten użytkownik lub grupa muszą być rozpoznawani w usłudze Azure NetApp Files poprzez połączenie z serwerem LDAP podczas określania domeny identyfikatora NFSv4.x. Jeśli „name@domain” nie jest rozpoznawana przez usługę Azure NetApp Files, operacja ACL kończy się niepowodzeniem z błędem „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 w NFSv4.x

Lokalni użytkownicy i grupy mogą być również używane w 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 nie działają.

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 kontroli dostępu (ACL) dla użytkownika lokalnego lub grupy, każdy użytkownik lub grupa, która odpowiada identyfikatorowi liczbowemu na liście kontroli dostępu, uzyskuje dostęp do obiektu. W przypadku lokalnych list ACL grupowych użytkownik przekazuje swoje członkostwo 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.

Obraz przedstawiający przykładowe przechwytywanie pakietów z poświadczeniami.

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 liczbowego identyfikatora ACL usługa Azure NetApp Files automatycznie zakłada, że przychodzące żądanie jest prawidłowe i że użytkownik żądający dostępu jest tym, za kogo się podaje i należy do grup, do których twierdzi, że należy. Jeśli zły aktor zna numeryczny identyfikator użytkownika lub grupy i może uzyskać dostęp do sieci za pomocą klienta z możliwością lokalnego tworzenia użytkowników i grup, to istnieje ryzyko oszustwa.
  • 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.
  • Zdecydowanie zaleca się używanie ciągów LDAP i pełnych nazw@domen podczas korzystania z list ACL NFSv4.x, aby zapewnić lepszą możliwość zarządzania i ochrony. 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 głównej, gdzie 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 root), aby prawidłowo wyświetlać się na właścicielach plików/folderów.

Usługa Azure NetApp Files domyślnie przypisuje domenę ID NFSv4.x do ustawień domeny DNS woluminu. Klienci NFS domyślnie używają domeny DNS jako 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 określonego użytkownika lub grupy do pliku lub folderu. Uprawnienia w systemie plików NFSv3 pozwalają jedynie na poziomy dostępu do odczytu, zapisu i wykonywania (rwx), ale NFSv4.x zapewnia szereg innych szczegółowych mechanizmów kontroli dostępu, co stanowi ulepszenie w stosunku do 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 z danymi i listami
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 Odczytywanie atrybutów (GETATTR)
T Ustawianie atrybutów (SETATTR/chmod)
n Odczytywanie nazwanych atrybutów
N Zapisywanie nazwanych atrybutów
Bez kontekstu nie można zapewnić adekwatnego tłumaczenia litery "c". Odczytaj ACL
C Pisanie ACL
o Polecenie zmiany właściciela (chown)
y Synchroniczne operacje we/wy

Po ustawieniu uprawnień dostępu użytkownik lub podmiot zabezpieczeń grupy działa zgodnie z 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 wszelki dostęp do zapisu (danych, atrybutów, właścicielowi) jest zabroniony.

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, jakie szczegółowe mechanizmy kontroli mogą zapewniać listy ACL w NFSv4.x.

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 ACL NFSv4.x

Gdy chmod jest uruchamiany na obiekcie, który ma przypisane listy ACL NFSv4.x, seria list ACL systemu jest aktualizowana 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 bicie trybu przekłada się na uprawnienia ACL NFSv4.

Zobacz uprawnienia NFSv4.x, aby zapoznać się z tabelą przedstawiającą wszystkie uprawnienia.

Tryb bitowy numeryczny Odpowiednie uprawnienia NFSv4.x
1 — wykonaj (x) Wykonywanie, odczytywanie atrybutów, odczytywanie list ACL, synchronizowanie operacji we/wy (xtcy)
2 — pisz (w) Zapisywanie, dołączanie danych, odczytywanie atrybutów, zapisywanie atrybutów, zapisywanie nazwanych atrybutów, odczytywanie ACL, synchronizacja operacji we/wy (watTNcy)
3 — zapis/wykonanie (wx) Zapisywanie, dołączanie danych, wykonywanie, odczytywanie atrybutów, zapisywanie atrybutów, zapisywanie nazwanych atrybutów, odczytywanie list ACL, synchronizacja we/wy (waxtTNcy)
4 — odczyt (r) Odczytywanie, odczytywanie atrybutów, odczytywanie nazwanych atrybutów, odczytywanie list ACL, synchronizowanie operacji we/wy (rtncy)
5 — odczyt/wykonanie (rx) Odczytanie, wykonywanie, odczytanie atrybutów, odczytanie nazwanych atrybutów, odczytanie list kontroli dostępu, synchronizacja wejścia/wyjścia (rxtncy)
6 — odczyt/zapis (rw) Odczyt, zapis, dołączanie danych, odczyt atrybutów, zapis atrybutów, odczyt atrybutów nazwanych, zapis atrybutów nazwanych, odczyt list ACL, synchronizacja we/wy (rwatTnNcy)
7 — odczyt/zapis/wykonanie (rwx) Pełna kontrola/wszystkie uprawnienia

Jak listy ACL NFSv4.x działają w usłudze Azure NetApp Files

Usługa Azure NetApp Files natywnie obsługuje listy ACL NFSv4.x, gdy wolumin ma włączony dostęp do NFSv4.1. Nie ma nic do włączenia na woluminie dla obsługi ACL, ale aby listy ACL NFSv4.1 działały najlepiej, serwer LDAP z użytkownikami i grupami systemu UNIX jest wymagany, aby usługa Azure NetApp Files mogła bezpiecznie rozpoznać podmioty zabezpieczeń ustawione na listach ACL. Użytkownicy lokalni mogą być używani z listami ACL NFSv4.x, ale nie zapewniają tego samego poziomu bezpieczeństwa co listy ACL używane z serwerem LDAP.

Należy mieć na uwadze funkcjonalność ACL w usłudze Azure NetApp Files.

Dziedziczenie ACL

W usłudze Azure NetApp Files flagi dziedziczenia ACL mogą być używane do uproszczenia zarządzania listami kontroli dostępu (ACL) w NFSv4.x. Gdy ustawiona jest flaga dziedziczenia, listy kontroli dostępu (ACL) w katalogu nadrzędnym mogą być propagowane do podkatalogów i plików bez dalszej interakcji. Usługa Azure NetApp Files implementuje standardowe dziedziczenie zachowań ACL zgodnie z specyfikacją RFC-7530.

Odmowa kontroli dostępu

Reguły odmowy ACE w usłudze Azure NetApp Files są używane do jednoznacznego ograniczenia dostępu użytkownika lub grupy do pliku lub folderu. Podzbiór uprawnień można zdefiniować, aby zapewnić szczegółowe opcje zarządzania odmowami ACE. Działają one w standardowych metodach wymienionych w RFC-7530.

Zachowanie ACL

Gdy polecenie chmod jest wykonywane na pliku lub folderze w usłudze Azure NetApp Files, wszystkie istniejące wpisy ACE zostają zachowane w liście ACL z wyjątkiem systemowych ACE (OWNER@, GROUP@, EVERYONE@). Te uprawnienia ACE są modyfikowane jak określono 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 list kontroli dostępu (ACL) NFSv4.x w środowiskach dwu-protokółowych

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 kontrolne dostępu (ACL) NFSv4.x są używane w woluminach w stylu zabezpieczeń systemu UNIX, podczas korzystania z woluminów dwuprotokołowych i 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 UNIX odpowiadający użytkownikowi Windows, do mapowania używany jest domyślny użytkownik UNIX z nazwą zastępczą pcuser (z numerem uid 65534).
  • Pliki zapisane przez użytkowników systemu Windows bez prawidłowego mapowania na użytkowników systemu UNIX są wyświetlane jako należące do numerycznego identyfikatora 65534, który odpowiada nazwom użytkowników "nfsnobody" lub "nobody" w klientach systemu Linux używających zamontowań 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 -lan polecenia .
  • Pliki z nieprawidłowymi właścicielami nie zapewniają oczekiwanych wyników z bitów trybu UNIX ani z ACL NFSv4.x.
  • ACL-e NFSv4.x są zarządzane przez klientów NFS. Klienci SMB nie mogą wyświetlać list kontroli dostępu (ACL) NFSv4.x ani zarządzać nimi.

Wpływ maski Umask z listami ACL NFSv4.x

ACL NFSv4 zapewniają możliwość umożliwienia dziedziczenia 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.

Umask jest używany do kontrolowania poziomu uprawnień, z jakim pliki i foldery są tworzone w nowym katalogu. Domyślnie usługa Azure NetApp Files pozwala umask przesłonić dziedziczone listy ACL, co jest oczekiwanym zachowaniem zgodnie z RFC-7530.

Aby uzyskać więcej informacji, zobacz umask.

Działanie poleceń chmod/chown z listami ACL w systemie NFSv4.x

W usłudze Azure NetApp Files, można użyć poleceń zmiany własności (chown) i zmiany trybu (chmod), aby zarządzać uprawnieniami do plików i katalogów w systemach NFSv3 i NFSv4.x.

Korzystanie z list ACL NFSv4.x powoduje, że bardziej szczegółowe kontrole stosowane do plików i folderów zmniejszają potrzebę użycia poleceń chmod. Chown wciąż jest potrzebny, ponieważ listy ACL NFSv4.x nie przypisują własności użytkownika.

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 ACE jest modyfikowany w celu odzwierciedlenia tych bitów trybu. Jeśli systemowe ACE zostaną usunięte, bity trybu zostaną wyczyszczone. Przykłady i bardziej kompletny opis można znaleźć w sekcji poniżej dotyczącej systemowych ACE.

Po uruchomieniu polecenia chown w usłudze Azure NetApp Files można zmodyfikować przypisanego właściciela. Własność pliku nie jest tak istotna przy korzystaniu z list ACL NFSv4.x, jak przy używaniu bitów trybu, ponieważ listy ACL pozwalają na kontrolowanie uprawnień w sposób, którego nie umożliwiają podstawowe pojęcia właściciel/grupa/wszyscy. Narzędzie Chown w usłudze Azure NetApp Files może być uruchamiane tylko jako użytkownik root (jako użytkownik root lub przy użyciu polecenia sudo), ponieważ reguły eksportu są skonfigurowane tak, aby zezwalały tylko użytkownikowi root 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 Zasady eksportu dla woluminu zmodyfikuj tryb Chown na "nieograniczony".

Zrzut ekranu przedstawiający menu zasad eksportu ze zmianą trybu chown na 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 ACL "Przejęcie na własność" dla NFSv4.x (oznaczonego 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 wejścia kontroli dostępu

Na każdej liście ACL istnieje szereg systemowych ACE: 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 chmod jest uruchamiany na obiekcie, systemowe listy ACL zmieniają się, aby odzwierciedlić te uprawnienia.

# 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 wpisów ACE to sposób na dalsze zabezpieczanie plików i folderów, ponieważ tylko podmioty użytkowników i grup na liście ACL (oraz root) mogą uzyskiwać dostęp do obiektu. Usunięcie systemowych ACE może zakłócić działanie aplikacji, które opierają się na widokach bitów trybu dla swojej funkcjonalności.

Zachowanie użytkownika root z listami ACL NFSv4.x

Dostęp administratora za pomocą list ACL NFSv4.x nie może być ograniczony, chyba że użytkownik root jest zredukowany. Root squashing to reguła w polityce eksportu, w której root jest mapowany na anonimowego użytkownika w celu ograniczenia dostępu. Dostęp root można skonfigurować z menu zasady eksportu woluminu, zmieniając regułę dostępu głównego na wyłączone.

Aby skonfigurować scisanie katalogu głównego, przejdź do menu polityki eksportu na woluminie, a następnie zmień "Dostęp główny" na "wyłączony" dla reguły polityki.

Zrzut ekranu przedstawiający menu zasad eksportu z wyłączonym dostępem głównym.

Efekt wyłączenia funkcji squashowania root dla anonimowego użytkownika nfsnobody:65534. Dostęp do konta root 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.

Następne kroki