Delen via

Inzicht in NFSv4.x-toegangsbeheerlijsten in Azure NetApp Files

  • Artikel

Het NFSv4.x-protocol kan toegangsbeheer bieden in de vorm van toegangsbeheerlijsten (ACL's), die conceptueel vergelijkbaar zijn met ACL's die worden gebruikt in SMB via Windows NTFS-machtigingen. Een NFSv4.x ACL bestaat uit afzonderlijke ACL's (Access Control Entries) die elk een toegangsbeheerrichtlijn aan de server bieden.

Diagram van de entiteit voor toegangsbeheer naar Azure NetApp Files.

Elke NFSv4.x ACL wordt gemaakt met de indeling van type:flags:principal:permissions.

  • Type : het type ACL dat wordt gedefinieerd. Geldige opties zijn Access (A), Deny (D), Audit (U), Alarm (L). Azure NetApp Files ondersteunt toegangs-, weigeren- en controle-ACL-typen, maar audit-ACL's, terwijl ze kunnen worden ingesteld, produceren momenteel geen auditlogboeken.
  • Vlaggen : voegt extra context toe voor een ACL. Er zijn drie soorten ACE-vlaggen: groep, overname en beheer. Zie NFSv4.x ACE-vlaggen voor meer informatie over vlaggen.
  • Principal : definieert de gebruiker of groep waaraan de ACL wordt toegewezen. Een principal op een NFSv4.x ACL gebruikt de indeling van name@ID-DOMAIN-STRING.COM. Zie NFSv4.x user and group principals (NFSv4.x) voor meer informatie over principals.
  • Machtigingen , waarbij het toegangsniveau voor de principal is gedefinieerd. Elke machtiging wordt toegewezen aan één letter (lees krijgt bijvoorbeeld 'r', schrijven krijgt 'w' enzovoort). Volledige toegang zou elke beschikbare machtigingsbrief bevatten. Zie NFSv4.x-machtigingen voor meer informatie.

A:g:group1@contoso.com:rwatTnNcCy is een voorbeeld van een geldige ACL, volgens de type:flags:principal:permissions indeling. Het voorbeeld-ACL verleent volledige toegang tot de groep group1 in het contoso.com-id-domein.

NFSv4.x ACE-vlaggen

Met een ACE-vlag krijgt u meer informatie over een ACE in een ACL. Als een groeps-ACE bijvoorbeeld wordt toegevoegd aan een ACL, moet een groepsvlag worden gebruikt om de principal aan te wijzen, een groep en geen gebruiker. Het is mogelijk in Linux-omgevingen om een gebruiker en een groepsnaam te hebben die identiek zijn, dus de vlag zorgt ervoor dat een ACE wordt geëerd en de NFS-server moet weten welk type principal wordt gedefinieerd.

Andere vlaggen kunnen worden gebruikt om ACL's te beheren, zoals overname en administratieve vlaggen.

Toegangs- en weigeringsvlagmen

Toegangsvlagmen (A) en weigeren (D) worden gebruikt om beveiligings-ACE-typen te beheren. Een access ACE bepaalt het toegangsniveau voor een bestand of map voor een principal. Een deny ACE verbiedt expliciet dat een principal toegang krijgt tot een bestand of map, zelfs als een toegangs-ACE is ingesteld waarmee die principal toegang kan krijgen tot het object. Toegangs-ACL's altijd overschrijven. Vermijd in het algemeen het gebruik van ACL's voor weigeren, omdat NFSv4.x-ACL's een 'standaard weigeren'-model volgen, wat betekent dat als er geen ACL wordt toegevoegd, weigeren impliciet is. Weigeren van ACL's kan onnodige complicaties veroorzaken in ACL-beheer.

Overnamevlagmen

Overnamevlagmen bepalen hoe ACL's zich gedragen op bestanden die zijn gemaakt onder een bovenliggende map met de overnamevlag die is ingesteld. Wanneer een overnamevlag is ingesteld, nemen bestanden en/of mappen de ACL's over van de bovenliggende map. Overnamevlagmen kunnen alleen worden toegepast op mappen, dus wanneer een submap wordt gemaakt, wordt de vlag overgenomen. Bestanden die zijn gemaakt onder een bovenliggende map met een overnamevlag nemen ACL's over, maar niet de overnamevlagmen.

In de volgende tabel worden beschikbare overnamevlagmen en hun gedrag beschreven.

Overnamevlag Gedrag
d - Directory's onder de bovenliggende map nemen de ACL over
- Overnamevlag wordt ook overgenomen
f - Bestanden onder de bovenliggende map nemen de ACL over
- Bestanden stellen overnamevlag niet in
Ik Alleen overnemen; ACL is niet van toepassing op de huidige map, maar moet overname toepassen op objecten onder de map
n - Geen doorgifte van overname
Nadat de ACL is overgenomen, worden de overnamevlagmen gewist op de objecten onder het bovenliggende object

Voorbeelden van NFSv4.x ACL

In het volgende voorbeeld zijn er drie verschillende ACL's met afzonderlijke overnamevlagmen:

  • alleen map overnemen (di)
  • alleen bestand overnemen (fi)
  • zowel bestand als map overnemen (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 heeft alleen een ACL overgenomen. In een submap die onder het bovenliggende item is gemaakt, wordt de ACL overgenomen, maar op een bestand onder het bovenliggende bestand is dit niet.

# 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 heeft een vlag voor bestands- en directory-overname. Als gevolg hiervan nemen zowel bestanden als mappen onder een map met die ACE-vermelding de ACL over, maar bestanden nemen de vlag niet over.

# 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 heeft alleen een vlag voor het overnemen van bestanden. Als gevolg hiervan nemen alleen bestanden onder de map met die ACE-vermelding de ACL over, maar ze nemen de vlag niet over, omdat deze alleen kunnen worden toegepast op map-ACL's.

# 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

Wanneer een vlag 'no-propagate' (n) is ingesteld op een ACL, worden de vlaggen gewist bij volgende mapcreaties onder het bovenliggende item. In het volgende voorbeeld user2 is de n vlag ingesteld. Als gevolg hiervan wist de submap de overnemende vlaggen voor die principal en objecten die onder die submap zijn gemaakt, niet de ACE overnemen van 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

Het overnemen van vlaggen is een manier om uw ACL's voor NFSv4.x gemakkelijker te beheren, zodat u geen ACL expliciet kunt instellen wanneer u er een nodig hebt.

Beheervlagmen

Beheervlagmen in NFSv4.x ACL's zijn speciale vlaggen die alleen worden gebruikt met ACL-typen Controle en Alarm. Deze vlaggen definiëren geslaagde (S) of mislukteF () toegangspogingen voor acties die moeten worden uitgevoerd.

Azure NetApp Files biedt ondersteuning voor het instellen van beheervlagken voor audit-ACL's, maar de ACL's werken niet. Bovendien worden alarm-ACL's niet ondersteund in Azure NetApp Files.

NFSv4.x-principals voor gebruikers en groepen

Met ACL's voor NFSv4.x definiëren gebruikers- en groepsprincipals de specifieke objecten waarop een ACE moet worden toegepast. Principals volgen over het algemeen een indeling van name@ID-DOMAIN-STRING.COM. Het gedeelte 'naam' van een principal kan een gebruiker of groep zijn, maar die gebruiker of groep moet kunnen worden omgezet in Azure NetApp Files via de LDAP-serververbinding wanneer u het NFSv4.x-id-domein opgeeft. Als de name@domain niet kan worden omgezet door Azure NetApp Files, mislukt de ACL-bewerking met een fout 'ongeldig argument'.

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

U kunt in Azure NetApp Files controleren of een naam kan worden omgezet met behulp van de lijst met LDAP-groeps-id's. Navigeer naar Ondersteuning en probleemoplossing en vervolgens naar de lijst met LDAP-groeps-id's.

Lokale gebruikers- en groepstoegang via NFSv4.x ACL's

Lokale gebruikers en groepen kunnen ook worden gebruikt op een NFSv4.x ACL als alleen de numerieke id is opgegeven in de ACL. Gebruikersnamen of numerieke id's met een opgegeven domein-id mislukken.

Bijvoorbeeld:

# 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

Wanneer een lokale gebruiker of groeps-ACL is ingesteld, ontvangt elke gebruiker of groep die overeenkomt met de numerieke id op de ACL toegang tot het object. Voor ACL's voor lokale groepen geeft een gebruiker de groepslidmaatschappen door aan Azure NetApp Files. Als de numerieke id van de groep met toegang tot het bestand via de aanvraag van de gebruiker wordt weergegeven op de Azure NetApp Files NFS-server, wordt toegang toegestaan volgens de ACL.

De referenties die van de client naar de server worden doorgegeven, kunnen worden weergegeven via een pakketopname, zoals hieronder wordt weergegeven.

Afbeelding van voorbeeldpakketopname met referenties.

Waarschuwingen:

  • Het gebruik van lokale gebruikers en groepen voor ACL's betekent dat elke client die toegang heeft tot de bestanden/mappen, overeenkomende gebruikers- en groeps-id's moet hebben.
  • Wanneer u een numerieke id voor een ACL gebruikt, vertrouwt Azure NetApp Files impliciet dat de binnenkomende aanvraag geldig is en dat de gebruiker die toegang aanvraagt, is wie hij of zij zegt dat hij of zij lid is van de groepen waarvan hij of zij claimt lid te zijn. Een numerieke gebruiker of groep kan worden vervalst als een slechte actor de numerieke id kent en toegang heeft tot het netwerk met behulp van een client met de mogelijkheid om gebruikers en groepen lokaal te maken.
  • Als een gebruiker lid is van meer dan 16 groepen, wordt elke groep na de zestiende groep (in alfanumerieke volgorde) de toegang tot het bestand of de map geweigerd, tenzij LDAP- en uitgebreide groepsondersteuning wordt gebruikt.
  • LDAP en volledige name@domain naamtekenreeksen worden ten zeerste aanbevolen bij het gebruik van ACL's voor NFSv4.x voor betere beheerbaarheid en beveiliging. Een centraal beheerde gebruikers- en groepsopslagplaats is eenvoudiger te onderhouden en moeilijker te spoofen, waardoor ongewenste gebruikerstoegang minder waarschijnlijk wordt.

NFSv4.x ID-domein

Het id-domein is een belangrijk onderdeel van de principal, waarbij een id-domein moet overeenkomen op zowel de client als binnen Azure NetApp Files voor gebruikers- en groepsnamen (met name root) om correct weer te geven voor eigendom van bestanden/mappen.

In Azure NetApp Files wordt het NFSv4.x-id-domein standaard ingesteld op de DNS-domeininstellingen voor het volume. NFS-clients worden ook standaard ingesteld op het DNS-domein voor het NFSv4.x ID-domein. Als het DNS-domein van de client verschilt van het DNS-domein van Azure NetApp Files, gebeurt er een onjuiste overeenkomst. Bij het weergeven van bestandsmachtigingen met opdrachten zoals ls, worden gebruikers/groepen weergegeven als 'niemand'.

Wanneer een domein niet overeenkomt tussen de NFS-client en Azure NetApp Files, controleert u de clientlogboeken op fouten die vergelijkbaar zijn met:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

Het id-domein van de NFS-client kan worden overschreven met behulp van de instelling 'Domein' van het bestand /etc/idmapd.conf. Voorbeeld: Domain = CONTOSO.COM.

Met Azure NetApp Files kunt u ook het NFSv4.1-id-domein wijzigen. Zie Procedure: NFSv4.1-id-domeinconfiguratie voor Azure NetApp Files voor meer informatie.

NFSv4.x-machtigingen

NFSv4.x-machtigingen zijn de manier om te bepalen welk toegangsniveau een specifieke gebruiker of groepsprincipaal heeft op een bestand of map. Machtigingen in NFSv3 staan alleen lees-/schrijf-/uitvoerniveaus van toegangsdefinities toe, maar NFSv4.x biedt een aantal andere gedetailleerde toegangscontroles als verbetering ten opzichte van NFSv3-modus bits.

Er zijn 13 machtigingen die kunnen worden ingesteld voor gebruikers en 14 machtigingen die kunnen worden ingesteld voor groepen.

Machtigingsbrief Machtiging verleend
r Gegevens lezen/bestanden en mappen weergeven
w Gegevens schrijven/bestanden en mappen maken
a Gegevens toevoegen/submappen maken
x Bestanden uitvoeren/mappen doorlopen
d Bestanden/mappen verwijderen
D Submappen verwijderen (alleen mappen)
h Kenmerken lezen (GETATTR)
T Schrijfkenmerken (SETATTR/chmod)
n Benoemde kenmerken lezen
N Benoemde kenmerken schrijven
c ACL's lezen
E ACL's schrijven
o Eigenaar schrijven (chown)
y Synchrone I/O

Wanneer toegangsmachtigingen zijn ingesteld, voldoet een gebruiker of groepsprincipaal aan de toegewezen rechten.

Voorbeelden van NFSv4.x-machtigingen

In de volgende voorbeelden ziet u hoe verschillende machtigingen werken met verschillende configuratiescenario's.

Gebruiker met leestoegang (alleen r)

Met alleen-lezentoegang kan een gebruiker kenmerken en gegevens lezen, maar schrijftoegang (gegevens, kenmerken, eigenaar) wordt geweigerd.

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

Gebruiker met leestoegang (r) en schrijfkenmerken (T)

In dit voorbeeld kunnen machtigingen voor het bestand worden gewijzigd vanwege de machtiging schrijfkenmerken (T), maar er kunnen geen bestanden worden gemaakt omdat alleen leestoegang is toegestaan. Deze configuratie illustreert het soort gedetailleerde besturingselementen NFSv4.x ACL's die kunnen worden geboden.

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

Modus-bits omzetten in NFSv4.x ACL-machtigingen

Wanneer een chmod een object uitvoert waaraan NFSv4.x ACL's zijn toegewezen, wordt een reeks systeem-ACL's bijgewerkt met nieuwe machtigingen. Als de machtigingen bijvoorbeeld zijn ingesteld op 755, worden de systeem-ACL-bestanden bijgewerkt. In de volgende tabel ziet u waarnaar elke numerieke waarde in een modusbit wordt omgezet in ACL-machtigingen voor NFSv4.

Zie NFSv4.x-machtigingen voor een tabel met alle machtigingen.

Modus-bits numeriek Bijbehorende NFSv4.x-machtigingen
1 – uitvoeren (x) Uitvoeren, kenmerken lezen, ACL's lezen, I/O synchroniseren (xtcy)
2 – schrijven (w) Schrijven, toevoegen van gegevens, leeskenmerken, schrijfkenmerken, benoemde kenmerken schrijven, ACL's lezen, I/O synchroniseren (watTNcy)
3 – schrijven/uitvoeren (wx) Schrijven, toevoeggegevens, uitvoeren, kenmerken lezen, schrijfkenmerken, benoemde kenmerken schrijven, ACL's lezen, I/O synchroniseren (waxtTNcy)
4 – lezen (r) Lees-, leeskenmerken, benoemde kenmerken lezen, ACL's lezen, I/O synchroniseren (rtncy)
5 – lezen/uitvoeren (rx) Kenmerken lezen, uitvoeren, lezen, benoemde kenmerken lezen, ACL's lezen, I/O synchroniseren (rxtncy)
6 – lezen/schrijven (rw) Lezen, schrijven, toevoegen van gegevens, leeskenmerken, schrijfkenmerken, benoemde kenmerken lezen, benoemde kenmerken schrijven, lees-ACL's, synchronisatie-I/O (rwatTnNcy)
7 – lezen/schrijven/uitvoeren (rwx) Volledig beheer/alle machtigingen

Hoe NFSv4.x ACL's werken met Azure NetApp Files

Azure NetApp Files ondersteunt systeemeigen NFSv4.x ACL's wanneer op een volume NFSv4.1 is ingeschakeld voor toegang. Er is niets om het volume in te schakelen voor ACL-ondersteuning, maar voor ACL's voor NFSv4.1 werkt het beste een LDAP-server met UNIX-gebruikers en -groepen om ervoor te zorgen dat Azure NetApp Files de principals die zijn ingesteld op de ACL's veilig kan oplossen. Lokale gebruikers kunnen worden gebruikt met NFSv4.x ACL's, maar ze bieden niet hetzelfde beveiligingsniveau als ACL's die worden gebruikt met een LDAP-server.

Er zijn overwegingen waarmee u rekening moet houden met de ACL-functionaliteit in Azure NetApp Files.

Overname van ACL

In Azure NetApp Files kunnen ACL-overnamevlagmen worden gebruikt om ACL-beheer te vereenvoudigen met ACL's van NFSv4.x. Wanneer een overnamevlag is ingesteld, kunnen ACL's in een bovenliggende map worden doorgegeven aan submappen en bestanden zonder verdere interactie. Azure NetApp Files implementeert standaard-ACL-overgenomen gedrag volgens RFC-7530.

ACL's weigeren

ACL's weigeren in Azure NetApp Files worden gebruikt om expliciet te beperken dat een gebruiker of groep toegang heeft tot een bestand of map. Een subset van machtigingen kan worden gedefinieerd om gedetailleerde besturingselementen te bieden voor de weigerings-ACE. Deze werken in de standaardmethoden die worden genoemd in RFC-7530.

ACL-behoud

Wanneer een chmod wordt uitgevoerd op een bestand of map in Azure NetApp Files, blijven alle bestaande ACL's behouden op de andere ACL dan de systeem-ACL's (OWNER@, GROUP@, EVERYONE@). Deze ACE-machtigingen worden gewijzigd zoals gedefinieerd door de numerieke modus bits die zijn gedefinieerd door de chmod-opdracht. Alleen ACL's die handmatig worden gewijzigd of verwijderd via de nfs4_setfacl opdracht, kunnen worden gewijzigd.

NFSv4.x ACL-gedrag in omgevingen met twee protocollen

Dual-protocol verwijst naar het gebruik van zowel SMB als NFS op hetzelfde Azure NetApp Files-volume. Besturingselementen voor toegang met twee protocollen worden bepaald door welke beveiligingsstijl het volume gebruikt, maar de toewijzing van gebruikersnamen zorgt ervoor dat Windows-gebruikers en UNIX-gebruikers die met succes aan elkaar zijn toegewezen, dezelfde toegangsmachtigingen hebben voor gegevens.

Wanneer NFSv4.x ACL's worden gebruikt op UNIX-beveiligingsstijlvolumes, kunnen de volgende gedragingen worden waargenomen bij het gebruik van volumes met twee protocollen en het openen van gegevens van SMB-clients.

  • Windows-gebruikersnamen moeten correct worden toegewezen aan UNIX-gebruikersnamen voor de juiste oplossing voor toegangsbeheer.
  • In UNIX-beveiligingsstijlvolumes (waarbij NFSv4.x ACL's zouden worden toegepast), als er geen geldige UNIX-gebruiker bestaat op de LDAP-server waarnaar een Windows-gebruiker kan worden toegewezen, wordt een standaard UNIX-gebruiker met de naam pcuser (met uid numeriek 65534) gebruikt voor toewijzing.
  • Bestanden die zijn geschreven met Windows-gebruikers zonder geldige UNIX-gebruikerstoewijzing worden weergegeven als eigendom van numerieke id 65534, die overeenkomt met 'nfsnobody' of 'niemand' gebruikersnamen in Linux-clients vanuit NFS-koppelingen. Dit verschilt van de numerieke id 99, die meestal wordt gezien met NFSv4.x ID-domeinproblemen. Gebruik de ls -lan opdracht om de numerieke id in gebruik te controleren.
  • Bestanden met onjuiste eigenaren bieden geen verwachte resultaten van UNIX-modus-bits of NFSv4.x ACL's.
  • NFSv4.x ACL's worden beheerd vanuit NFS-clients. SMB-clients kunnen NFSv4.x ACL's niet weergeven of beheren.

Umask-impact met NFSv4.x ACL's

NFSv4 ACL's bieden de mogelijkheid om ACL-overname te bieden. Overname van ACL betekent dat bestanden of mappen die zijn gemaakt onder objecten met set NFSv4 ACL's, de ACL's kunnen overnemen op basis van de configuratie van de ACL-overnamevlag.

Umask wordt gebruikt om het machtigingsniveau te bepalen waarop bestanden en mappen worden gemaakt in een map. Standaard staat Azure NetApp Files toe dat umask overgenomen ACL's overschrijft. Dit gedrag wordt verwacht volgens RFC-7530.

Zie umask voor meer informatie.

Gedrag chmod/chown met NFSv4.x ACL's

In Azure NetApp Files kunt u het eigendom wijzigen (chown) en de modus-bitopdrachten (chmod) wijzigen voor het beheren van bestands- en mapmachtigingen voor NFSv3 en NFSv4.x.

Wanneer u NFSv4.x ACL's gebruikt, vermindert de meer gedetailleerde besturingselementen die worden toegepast op bestanden en mappen de noodzaak van chmod-opdrachten. Chown heeft nog steeds een locatie, omdat NFSv4.x ACL's geen eigendom toewijzen.

Wanneer chmod wordt uitgevoerd in Azure NetApp Files op bestanden en mappen waarop NFSv4.x ACL's zijn toegepast, worden modus-bits voor het object gewijzigd. Daarnaast wordt een set systeem-ACL's aangepast om deze modus-bits weer te geven. Als de systeem-ACL's worden verwijderd, worden de modus-bits gewist. Voorbeelden en een meer volledige beschrijving vindt u in de sectie over systeem-ACL's hieronder.

Wanneer chown wordt uitgevoerd in Azure NetApp Files, kan de toegewezen eigenaar worden gewijzigd. Het eigendom van bestanden is niet zo kritiek wanneer u NFSv4.x ACL's gebruikt als bij het gebruik van modus-bits, omdat ACL's kunnen worden gebruikt om machtigingen te beheren op manieren die basisconcepten van eigenaar/groep/iedereen niet konden. Chown in Azure NetApp Files kan alleen worden uitgevoerd als root (als root of met sudo), omdat exportbesturingselementen zijn geconfigureerd om alleen root toe te staan om eigendomswijzigingen aan te brengen. Omdat dit wordt beheerd door een standaardregel voor exportbeleid in Azure NetApp Files, zijn NFSv4.x ACL-vermeldingen die eigendomswijzigingen toestaan niet van toepassing.

# 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

De exportbeleidsregel op het volume kan worden gewijzigd om dit gedrag te wijzigen. Wijzig in het menu Beleid exporteren voor het volume de modus Chown in 'onbeperkt'.

Schermopname van het menu Exportbeleid waarin de modus Chown wordt gewijzigd in onbeperkt.

Zodra het eigendom is gewijzigd, kan het eigendom worden gewijzigd door andere gebruikers dan de hoofdmap als ze over de juiste toegangsrechten beschikken. Hiervoor is de NFSv4.x ACL-machtiging (aangewezen door de letter 'o') vereist. Het eigendom kan ook worden gewijzigd als de gebruiker het eigendom van het bestand of de map wijzigt.

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

Systeem-ACL's

Op elke ACL zijn er een reeks systeem-ACL's: OWNER@, GROUP@, EVERYONE@. Voorbeeld:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

Deze ACL's komen overeen met de machtigingen voor klassieke modus bits die u in NFSv3 zou zien en die rechtstreeks aan deze machtigingen zijn gekoppeld. Wanneer een chmod wordt uitgevoerd op een object, worden deze systeem-ACL's gewijzigd zodat deze machtigingen worden weergegeven.

# 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

Als deze systeem-ACL's worden verwijderd, verandert de machtigingsweergave zodanig dat de normale modus bits (rwx) worden weergegeven als streepjes.

# 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

Het verwijderen van systeem-ACL's is een manier om bestanden en mappen verder te beveiligen, omdat alleen de gebruikers- en groepsprinciplen op de ACL (en hoofdmap) toegang hebben tot het object. Door systeem-ACL's te verwijderen, kunnen toepassingen die afhankelijk zijn van modusbitweergaven voor functionaliteit worden verbroken.

Gedrag van hoofdgebruikers met NFSv4.x-ACL's

Toegang tot de hoofdmap met NFSv4.x ACL's kan niet worden beperkt, tenzij root wordt platgedrukt. Root-squashing is waar een exportbeleidsregel wordt geconfigureerd waar root wordt toegewezen aan een anonieme gebruiker om de toegang te beperken. Hoofdtoegang kan worden geconfigureerd vanuit het menu Exportbeleid van een volume door de beleidsregel van hoofdtoegang te wijzigen in uit.

Als u root-squashing wilt configureren, gaat u naar het menu Beleid exporteren op het volume en wijzigt u 'Hoofdtoegang' in 'uit' voor de beleidsregel.

Schermopname van het menu Beleid exporteren met hoofdtoegang uitgeschakeld.

Het effect van het uitschakelen van root access root root squashes aan anonieme gebruiker nfsnobody:65534. De basistoegang kan vervolgens het eigendom niet wijzigen.

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

In omgevingen met twee protocollen kunnen NTFS-ACL's ook worden gebruikt om de toegang tot de hoofdmap nauwkeurig te beperken.

Volgende stappen