Förstå NFSv4.x-åtkomstkontrollistor i Azure NetApp Files

NFSv4.x-protokollet kan ge åtkomstkontroll i form av åtkomstkontrollistor (ACL), som konceptuellt liknar ACL:er som används i SMB via Windows NTFS-behörigheter. En NFSv4.x ACL består av enskilda åtkomstkontrollposter (ACL), som var och en tillhandahåller ett åtkomstkontrolldirektiv till servern.

Varje NFSv4.x ACL använder formatet type:flags:principal:permissions.

Typ – den typ av ACL som definieras. Giltiga alternativ är Åtkomst (A), Neka (D), Granskning (U), Larm (L). Azure NetApp Files har stöd för åtkomst-, neka- och gransknings-ACL-typer, men Granska ACL:er, samtidigt som de kan ställas in, skapar för närvarande inte granskningsloggar.
Flaggor – lägger till extra kontext för en ACL. Det finns tre typer av ACE-flaggor: grupp, arv och administration. Mer information om flaggor finns i NFSv4.x ACE-flaggor.
Principal – definierar den användare eller grupp som tilldelas åtkomstkontrollistan. En principal i en NFSv4.x ACL använder formatet name@ID-DOMAIN-STRING.COM. För mer detaljerad information om principaler, se NFSv4.x-användar- och gruppprincipaler.
Behörigheter – hur åtkomstnivån för huvudkontot definieras. Behörigheter anges med en enda bokstav. Till exempel ger "r" läsbehörigheter, "w" ger skrivbehörigheter. Fullständig åtkomst skulle omfatta varje tillgängligt behörighetsbrev. Mer information finns i NFSv4.x-behörigheter.

A:g:group1@contoso.com:rwatTnNcCy är ett exempel på en giltig ACL som följer type:flags:principal:permissions formatet. Exempel-ACL ger fullständig åtkomst till gruppen group1 i domänen contoso.com ID.

NFSv4.x ACE-flaggor

En ACE-flagga hjälper till att ge mer information om ett ACE i en ACL. Om en grupp-ACE till exempel läggs till i en ACL måste en gruppflagga användas för att ange att principalen är en grupp och inte en användare. Det är möjligt i Linux-miljöer att ha en användare och ett gruppnamn som är identiska, så flaggan ser till att ett ACE respekteras, och sedan måste NFS-servern veta vilken typ av huvudnamn som definieras.

Andra flaggor kan användas för att styra ACL:er, till exempel arvsflaggor och administrativa flaggor.

Åtkomst- och spärrflaggor

Åtkomstflaggor (A) och neka (D) används för att kontrollera SÄKERHETS-ACE-typer. Ett access-ACE kontrollerar åtkomstbehörigheterna för en fil eller mapp för en huvudman. En nekande ACE förbjuder uttryckligen en användare från att komma åt en fil eller mapp, även om en åtkomst-ACE har angetts som skulle tillåta att användaren får åtkomst till objektet. Neka ACL:er överskrider alltid åtkomst-ACL:er. I allmänhet bör du undvika att använda neka ACL:er eftersom NFSv4.x-ACL:er följer en "standard neka"-modell, vilket innebär att om en ACL inte läggs till är neka implicit. Neka ACE:er kan skapa onödiga komplikationer i ACL-hantering.

Arvsflaggor

Arvsflaggor styr hur ACL:er beter sig på filer som skapats under en överordnad katalog med arvsflaggan inställd. När en arvsflagga har angetts ärver filer och/eller kataloger ACL:erna från den överordnade mappen. Arvsflaggor kan bara tillämpas på kataloger, så när en underkatalog skapas ärver den flaggan. Filer som skapas under en överordnad katalog med en arvsflagga ärver ACL:er, men inte arvsflaggor.

I följande tabell beskrivs tillgängliga arvsflaggor och deras beteenden.

Arvsflagga	Funktionssätt
d	– Kataloger under den överordnade katalogen ärver ACL:n - Arvsflaggan ärvs också
f	– Filer under den överordnade katalogen ärver ACL:en – Filer anger inte arvflaggan som standard
jag	Ärv endast; ACL gäller inte för den aktuella katalogen men måste tillämpa arv på objekt under katalogen
n	- Ingen spridning av arv När ACL ärvs rensas ärvningsflaggor på objekten under det överordnade objektet.

NFSv4.x ACL-exempel

I följande exempel finns det tre olika ACE:er med distinkta arvsflaggor.

(di) – katalog endast för arv
(fi) – endast fil ärver
(fdi) – både fil och katalog ärver

# 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 har endast en katalog som ärver ACL. På en underkatalog som skapas under den överordnade katalogen ärvs ACL:en, men för en fil under den överordnade ärvs den inte.

# 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 har en fil- och katalogärvningsflagg. Därför ärver både filer och kataloger under en katalog med den ACE-posten ACL,men filerna ärver inte flaggan.

# 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 har bara en fil ärvd flagga. Det innebär att endast filer under katalogen med den ACE-posten ärver ACL:en, men de ärver inte flaggan eftersom den bara kan tillämpas på katalog-ACL:er.

# 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

När en "no-propagate"-flagga (n) anges på en ACL tas flaggorna bort vid efterföljande katalogskapanden under den överordnade katalogen. I följande exempel har user2 flaggan n inställd. Därför rensar underkatalogen ärvflaggorna för den huvudprincipen, och befintliga objekt skapade under den underliggande underkatalogen ärver inte ACE från 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

Arvflaggor är ett sätt att enklare hantera dina NFSv4.x-ACL:er, vilket sparar dig från att uttryckligen ange en ACL varje gång du behöver en.

Administrativa flaggor

Administrativa flaggor i NFSv4.x-ACL:er är särskilda flaggor som endast används med gransknings- och larm-ACL:er. Dessa flaggor definierar antingen lyckade (S) eller misslyckade (F) åtkomstförsök för åtgärder som ska utföras.

Den här gransknings-ACL:en är ett exempel på det, där user1 granskas för misslyckade åtkomstförsök för valfri behörighetsnivå: U:F:user1@contoso.com:rwatTnNcCy.

Azure NetApp Files har endast stöd för att ange administrativa flaggor för gransknings-ACL:er. Revision-ACE:er krävs för filåtkomstloggar. Larm-ACL:er stöds inte i Azure NetApp Files.

NFSv4.x-användare och gruppprinciper

Med NFSv4.x-ACL:er definierar användar- och grupphuvudnamn de specifika objekt som ett ACE ska gälla för. Ansvariga följer vanligtvis ett format som name@ID-DOMAIN-STRING.COM. "Namn"-delen av ett huvudnamn kan vara en användare eller grupp, men den användaren eller gruppen måste kunna matchas i Azure NetApp Files via LDAP-serveranslutningen när du anger ID-domänen NFSv4.x. Om name@domain inte kan matchas av Azure NetApp Files misslyckas ACL-åtgärden med ett "ogiltigt argument"-fel.

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

Du kan kontrollera i Azure NetApp Files om ett namn kan lösas med hjälp av LDAP-grupp-ID-listan. Gå till Support + Felsökning och sedan LDAP-grupp-ID-lista.

Lokal användar- och gruppåtkomst via NFSv4.x-ACL:er

Lokala användare och grupper kan också användas på en NFSv4.x ACL om endast det numeriska ID:t anges i ACL. Användarnamn eller numeriska ID:n med ett angivet domän-ID misslyckas.

Till exempel:

# 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

När en lokal användare eller grupp-ACL har angetts får alla användare eller grupper som motsvarar det numeriska ID:t på ACL:n åtkomst till objektet. För lokala grupp-ACL:er skickar en användare sina gruppmedlemskap till Azure NetApp Files. Om det numeriska ID:t för gruppen med åtkomst till filen via användarens begäran visas för Azure NetApp Files NFS-servern tillåts åtkomst enligt ACL.

Autentiseringsuppgifterna som skickas från klienten till servern kan ses via en paketinsamling enligt nedan.

Varningar:

Att använda lokala användare och grupper för ACL:er innebär att varje klient som kommer åt filerna/mapparna måste ha matchande användar- och grupp-ID:t.
När du använder ett numeriskt ID för en ACL litar Azure NetApp Files implicit på att den inkommande begäran är giltig och att användaren som begär åtkomst är den som de säger sig vara och är medlem i de grupper som de påstår sig vara medlem i. En användare eller grupp numerisk kan förfalskas om en dålig aktör känner till det numeriska ID:t och kan komma åt nätverket med hjälp av en klient med möjlighet att skapa användare och grupper lokalt.
Om en användare är medlem i fler än 16 grupper nekas alla grupper efter den sextonde gruppen (i alfanumerisk ordning) åtkomst till filen eller mappen, såvida inte stöd för LDAP och utökad grupp används.
LDAP och fullständiga name@domain namnsträngar rekommenderas starkt när du använder NFSv4.x-ACL:er för bättre hanterbarhet och säkerhet. En centralt hanterad lagringsplats för användare och grupper är enklare att underhålla och svårare att förfalska, vilket gör oönskad användaråtkomst mindre sannolik.

NFSv4.x ID-domän

ID-domänen är en viktig komponent i huvudprincipen, där en ID-domän måste matcha både på klienten och i Azure NetApp Files för att användar- och gruppnamn, specifikt för rot, ska visas korrekt i fil- och mappägarskap.

Azure NetApp Files ställer in standardvärdet för NFSv4.x ID-domänen till DNS-domäninställningarna för volymen. NFS-klienter använder som standard DNS-domänen för NFSv4.x-ID-domän. Om klientens DNS-domän skiljer sig från DNS-domänen för Azure NetApp Files inträffar ett matchningsfel. När du listar filbehörigheter med kommandon som lsvisas användare/grupper som "ingen".

När ett domänmatchningsfel inträffar mellan NFS-klienten och Azure NetApp Files kontrollerar du klientloggarna efter fel som liknar:

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

NFS-klientens ID-domän kan åsidosättas med hjälp av inställningen "Domain" i filen /etc/idmapd.conf. Exempel: Domain = CONTOSO.COM.

Med Azure NetApp Files kan du också ändra ID-domänen NFSv4.1. Mer information finns i Instruktioner: NFSv4.1 ID-domänkonfiguration för Azure NetApp Files.

NFSv4.x-behörigheter

NFSv4.x-behörigheter är ett sätt att styra vilken åtkomstnivå en specifik användare eller grupphuvudnamn har på en fil eller mapp. Behörigheter i NFSv3 tillåter endast åtkomstnivåer för läs, skriv och kör (rwx), men NFSv4.x innehåller en mängd andra detaljerade åtkomstkontroller som en förbättring jämfört med NFSv3:s lägesbitar.

Det finns 13 behörigheter som kan anges för användare och 14 behörigheter som kan anges för grupper.

Behörighetsbrev	Behörighet beviljad
r	Läsa datafiler, listfiler och mappar
a	Skriva data/skapa filer och mappar
a	Lägga till data/skapa underkataloger
x	Köra filer/genomsöka kataloger
d	Ta bort filer/kataloger
D	Ta bort underkataloger (bara kataloger)
t	Läs attribut (GETATTR)
T	Skriv attribut (SETATTR/chmod)
n	Läsa namngivna attribut
N	Ange namngivna attribut
c	Läs ACL:er
C	Skriv ACL:er
o	Skriv ägare (chown)
y	Synkrona I/O

När åtkomstbehörigheter har ställts in följer en användare eller grupp de tilldelade rättigheterna.

NFSv4.x-behörighetsexempel

I följande exempel visas hur olika behörigheter fungerar med olika konfigurationsscenarier.

Användare med läsbehörighet (endast r)

Med skrivskyddad åtkomst kan en användare läsa attribut och data, men all skrivåtkomst (data, attribut, ägare) nekas.

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

Användare med läsåtkomst (r) och skrivattribut (T)

I det här exemplet kan behörigheter för filen ändras på grund av behörigheten skrivattribut (T), men inga filer kan skapas eftersom endast läsåtkomst tillåts. Den här konfigurationen illustrerar vilken typ av detaljerade kontroller NFSv4.x ACL:er kan tillhandahålla.

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

Översätta modebitar till NFSv4.x ACL-behörigheter

När en chmod körs på ett objekt med NFSv4.x-ACL:er tilldelade, uppdateras en serie system-ACL:er med nya behörigheter. Om behörigheterna till exempel är inställda på 755 uppdateras system-ACL-filerna. I följande tabell visas vad varje numeriskt värde i en lägesbit översätts till i NFSv4 ACL-behörigheter.

Se NFSv4.x-behörigheter för en tabell som beskriver alla behörigheter.

Läge, bit numeriskt	Motsvarande NFSv4.x-behörigheter
1 – kör (x)	Exekvera, läsa attribut, läsa ACL:er, synkronisera I/O (xtcy)
2 – skriva (w)	Skriva, lägga till data, läsa attribut, skriva attribut, skriva namngivna attribut, läsa ACL:er, synkronisera I/O (watTNcy)
3 – skriva/köra (wx)	Skriva, lägga till data, köra, läsa attribut, skriva attribut, skriva namngivna attribut, läsa ACL:er, synkronisera I/O (waxtTNcy)
4 – läs (r)	Läsa, läsa attribut, läsa namngivna attribut, läsa ACL:er, synkronisera I/O (rtncy)
5 – läsa/köra (rx)	Läsa, exekvera, läsa attribut, läsa namngivna attribut, läsa ACL:er, synkronisera I/O (rxtncy)
6 – läsa/skriva (rw)	Läsa, skriva, lägga till data, läsa attribut, skriva attribut, läsa namngivna attribut, skriva namngivna attribut, läsa ACL:er, synkronisera I/O (rwatTnNcy)
7 – läsa/skriva/exekvera (rwx)	Fullständig kontroll/alla behörigheter

Så här fungerar NFSv4.x-ACL:er med Azure NetApp Files

Azure NetApp Files stöder NFSv4.x-ACL:er internt när en volym har NFSv4.1 aktiverat för åtkomst. Det finns inget att aktivera på volymen för ACL-stöd, men för att NFSv4.1-ACL:er ska fungera bäst krävs en LDAP-server med UNIX-användare och -grupper för att säkerställa att Azure NetApp Files kan hantera de användarkonton som anges på ACL:erna på ett säkert sätt. Lokala användare kan användas med NFSv4.x-ACL:er, men de tillhandahåller inte samma säkerhetsnivå som ACL:er som används med en LDAP-server.

Det finns saker att tänka på med ACL-funktioner i Azure NetApp Files.

ACL-arvstruktur

I Azure NetApp Files kan ACL-arvsflaggor användas för att förenkla ACL-hanteringen med NFSv4.x-ACL:er. När en arvsflagga har angetts kan ACL:er i en överordnad katalog spridas ned till underkataloger och filer utan ytterligare interaktion. Azure NetApp Files implementerar standard-ACL:s som ärver beteenden i enlighet med RFC-7530.

Neka ACL:er

Nekande ACEs i Azure NetApp Files används för att uttryckligen förhindra en användare eller grupp att få tillgång till en fil eller mapp. En delmängd av behörigheter kan definieras för att tillhandahålla granulära kontroller över deny ACE. Dessa fungerar i standardmetoderna som nämns i RFC-7530.

Bevarande av ACL

När en chmod utförs på en fil eller mapp i Azure NetApp Files bevaras alla befintliga ACL:er på andra ACL än system-ACL:er (OWNER@, GROUP@, EVERYONE@). Dessa ACE-behörigheter ändras enligt definitionen av de numeriska lägesbitarna som definieras av kommandot chmod. Endast ACL:er som ändras eller tas bort manuellt via nfs4_setfacl kommandot kan ändras.

NFSv4.x ACL-beteenden i miljöer med dubbla protokoll

Dubbla protokoll avser användning av både SMB och NFS på samma Azure NetApp Files-volym. Åtkomstkontroller med dubbla protokoll bestäms av vilket säkerhetsformat volymen använder, men användarnamnsmappning säkerställer att Windows-användare och UNIX-användare som mappas till varandra har samma åtkomstbehörighet till data.

När NFSv4.x-ACL:er används på UNIX-säkerhetsformatvolymer kan följande beteenden observeras när du använder volymer med dubbla protokoll och åtkomst till data från SMB-klienter.

Windows-användarnamn måste mappas korrekt till UNIX-användarnamn för korrekt lösning av åtkomstkontroll.
I UNIX-säkerhetsformatvolymer (där NFSv4.x-ACL:er skulle tillämpas), om det inte finns någon giltig UNIX-användare på LDAP-servern för en Windows-användare att mappa till, används en UNIX-standardanvändare med namnet pcuser (med uid-numeriska 65534) för mappning.
Filer som skrivits med Windows-användare utan giltig UNIX-användarmappning visas som ägda av numeriskt ID 65534, vilket motsvarar "nfsnobody" eller "nobody" användarnamn på Linux-klienter vid NFS-monteringar. Detta skiljer sig från det numeriska ID 99 som vanligtvis visas med NFSv4.x ID-domänproblem. Använd kommandot för ls -lan att verifiera det numeriska ID som används.
Filer med felaktiga ägare ger inte förväntade resultat från UNIX-lägesbitar eller från NFSv4.x-ACL:er.
NFSv4.x ACL:er hanteras från NFS-klienter. SMB-klienter kan varken visa eller hantera NFSv4.x-ACL:er.

Umask påverkan av NFSv4.x ACL:er

NFSv4-ACL:er ger möjlighet att erbjuda ACL-arv. ACL-arv innebär att filer eller mappar som skapats under objekt med NFSv4-ACL:er kan ärva ACL:er baserat på konfigurationen av ACL-arvsflaggan.

Umask används för att styra behörighetsnivån där filer och mappar skapas i en katalog. Som standard tillåter Azure NetApp Files att umask åsidosätter ärvda ACL:er, vilket är förväntat enligt RFC-7530.

Mer information finns i umask.

Chmod/chown-beteende med NFSv4.x ACL:er

I Azure NetApp Files kan du använda kommandona change ownership (chown) och change mode bit (chmod) för att hantera fil- och katalogbehörigheter på NFSv3 och NFSv4.x.

När du använder NFSv4.x-ACL:er minskar de mer detaljerade kontroller som tillämpas på filer och mappar behovet av chmod-kommandon. Chown har fortfarande en plats eftersom NFSv4.x-ACL:er inte tilldelar ägarskap.

När chmod körs i Azure NetApp Files på filer och mappar med NFSv4.x-ACL:er tillämpade ändras lägesbitarna på objektet. Dessutom ändras en uppsättning system-ACE:er för att återspegla dessa lägesbitar. Om system-ACE:erna tas bort, rensas lägesbitarna. Exempel och en mer fullständig beskrivning finns i avsnittet om system-ACL:er nedan.

När chown körs i Azure NetApp Files kan den tilldelade ägaren ändras. Filägarskap är inte lika viktigt när du använder NFSv4.x-ACL:er som när du använder lägesbitar, eftersom ACL:er kan användas för att styra behörigheter på sätt som grundläggande ägar-/grupp-/alla-begrepp inte kunde. Chown i Azure NetApp Files kan bara köras som root-användare (antingen som root-användare eller med sudo), eftersom exportkontroller har konfigurerats för att endast tillåta root-användaren att göra ändringar av ägarskapet. Eftersom detta styrs av en standardregel för exportprinciper i Azure NetApp Files gäller inte NFSv4.x ACL-poster som tillåter ägarskapsändringar.

# 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

Exportprincipregeln på volymen kan ändras för att ändra det här beteendet. I menyn Exportpolicy för volymen, ändra Chown-läget till "obegränsat".

När ägarskapet har ändrats kan andra användare än roten ändra ägarskapet om de har rätt åtkomsträttigheter. Detta kräver behörigheten "Ta ägarskap" NFSv4.x ACL (anges med bokstaven "o"). Ägarskapet kan också ändras om användaren som byter ägarskap för närvarande äger filen eller mappen.

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

System-ACE:er

På varje ACL finns det en rad system-ACL:er: OWNER@, GROUP@, EVERYONE@. Till exempel:

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

Dessa ACL:er motsvarar de klassiska bitbehörigheter som du skulle se i NFSv3 och är direkt associerade med dessa behörigheter. När en chmod körs på ett objekt ändras dessa system-ACL:er för att återspegla dessa behörigheter.

# 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

Om dessa system-ACL:er tas bort ändras behörighetsvyn så att de normala lägesbitarna (rwx) visas som bindestreck.

# 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

Att ta bort system-ACL:er är ett sätt att ytterligare skydda filer och mappar, eftersom endast användarens och gruppens huvudnamn i ACL:en (och roten) kan komma åt objektet. Om du tar bort system-ACE:er kan applikationer som förlitar sig på lägesbitsvyer för sin funktionalitet sluta fungera.

Rotanvändarbeteende med NFSv4.x-ACL:er

Rotåtkomst med NFSv4.x-ACL:er kan inte begränsas om inte roten är krossad. Root squashing är en exportregel där root mappas till en anonym användare för att begränsa åtkomsten. Rotåtkomst kan konfigureras från en volyms exportprincipmeny genom att ändra principregeln för rotåtkomst till av.

Om du vill konfigurera rot squashning går du till menyn Exportprincip på volymen och ändrar sedan "Rotåtkomst" till "av" för principens regel.

Effekten av att inaktivera root squash för anonym användare nfsnobody:65534. Rotåtkomsten kan sedan inte ändra ägarskapet.

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

I miljöer med dubbla protokoll kan NTFS-ACL:er också användas för att granularly begränsa rotåtkomsten.

Nästa steg

Feedback

Var den här sidan till hjälp?

Last updated on 2025-07-10