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 skapas med 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. Ett huvudnamn på en NFSv4.x ACL använder formatet name@ID-DOMAIN-STRING.COM. Mer detaljerad information om huvudkonton finns i NFSv4.x-användare och grupphuvudnamn.
- Behörigheter – där åtkomstnivån för huvudkontot har definierats. Varje behörighet tilldelas en enda bokstav (till exempel läs hämtar "r", skriver får "w" och så vidare). 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 till exempel en grupp-ACE läggs till i en ACL måste en gruppflagga användas för att ange att huvudnamnet ä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 neka flaggor
Åtkomstflaggor (A) och neka (D) används för att kontrollera SÄKERHETS-ACE-typer. Ett ÅTKOMST-ACE styr åtkomstbehörighetsnivån för en fil eller mapp för ett huvudnamn. En nekande ACE förbjuder uttryckligen ett huvudnamn från att komma åt en fil eller mapp, även om ett ÅTKOMST-ACE har angetts som skulle tillåta att huvudkontot 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 ACL 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 arvsflagga |
| i | Ä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 ärvda flaggor på objekten under den överordnade |
NFSv4.x ACL-exempel
I följande exempel finns det tre olika ACL:er med distinkta arvsflaggor:
- katalog ärver endast (di)
- filen ärver endast (fi)
- både fil och katalog ärver (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 har endast en katalog som ärver ACL. På en underkatalog som skapas under den överordnade filen ärvs ACL:en, men i en fil under den överordnade filen är den inte det.
# 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 ärv flagga. 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-propogate"-flagga (n) anges på en ACL rensas flaggorna vid efterföljande katalogskapanden under det överordnade objektet. I följande exempel user2 har flaggan angetts n . Därför rensar underkatalogen ärvflaggor för det huvudkontot och objekt som skapats under 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
Ärv flaggor är ett sätt att enklare hantera dina NFSv4.x-ACL:er, vilket besparar dig från att uttryckligen ange en ACL varje gång du behöver en.
Administrativa flaggor
Administrativa flaggor i ACL:er för NFSv4.x är särskilda flaggor som endast används med typer av gransknings- och larm-ACL. Dessa flaggor definierar antingen lyckade (S) eller misslyckade (F) åtkomstförsök för åtgärder som ska utföras.
Azure NetApp Files har stöd för att ange administrativa flaggor för gransknings-ACL:er, men ACL:erna fungerar inte. Dessutom stöds inte larm-ACL:er i Azure NetApp Files.
NFSv4.x-användare och grupphuvudnamn
Med NFSv4.x-ACL:er definierar användar- och grupphuvudnamn de specifika objekt som ett ACE ska gälla för. Huvudnamn följer vanligtvis formatet 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 huvudnamnet, där en ID-domän måste matcha på både klienten och i Azure NetApp Files för att användar- och gruppnamn (specifikt rot) ska visas korrekt på fil-/mappägarskap.
Azure NetApp Files standarddomänen NFSv4.x ID till DNS-domäninställningarna för volymen. NFS-klienterna är också standard för DNS-domänen för NFSv4.x-ID-domänen. 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 domäninställningen /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 åtkomstdefinitionsnivåer för läsning/skrivning/körning (rwx), men NFSv4.x innehåller en mängd andra detaljerade åtkomstkontroller som en förbättring jämfört med NFSv3-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 data/listfiler och mappar |
| a | Skriva data/skapa filer och mappar |
| f | Lägga till data/skapa underkataloger |
| x | Köra filer/bläddra kataloger |
| d | Ta bort filer/kataloger |
| D | Ta bort underkataloger (endast kataloger) |
| d | Läsattribut (GETATTR) |
| T | Skrivattribut (SETATTR/chmod) |
| n | Läsa namngivna attribut |
| N | Skriva namngivna attribut |
| c | Läs ACL:er |
| C | Skriv ACL:er |
| o | Skriv ägare (chown) |
| y | Synkrona I/O |
När åtkomstbehörigheter har angetts följer användarens eller gruppens huvudnamn 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 lägesbitar till NFSv4.x ACL-behörigheter
När en chmod körs ett objekt med tilldelade NFSv4.x-ACL:er 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) | Köra, 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, köra, 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/köra (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 lösa de huvudkonton 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-arv
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 ärver beteenden enligt RFC-7530.
Neka ACL:er
Neka åtkomstkontrollistor i Azure NetApp Files används för att uttryckligen begränsa en användare eller grupp från att komma åt en fil eller mapp. En delmängd av behörigheter kan definieras för att tillhandahålla detaljerade kontroller över neka ACE. Dessa fungerar i standardmetoderna som nämns i RFC-7530.
ACL-bevarande
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 "ingen" användarnamn i Linux-klienter från 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 -lanatt 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.
Umaskpåverkan med 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-ACL:er för att återspegla dessa lägesbitar. Om system-ACL: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 rot (antingen som rot eller med sudo), eftersom exportkontroller har konfigurerats för att endast tillåta roten att göra ägarskapsändringar. 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 Exportera princip för volymen ändrar du Chown-läget till "obegränsad".
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-ACL: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-ACL:er kan program som förlitar sig på lägesbitvyer brytas för funktioner.
Rotanvändarbeteende med NFSv4.x-ACL:er
Rotåtkomst med NFSv4.x-ACL:er kan inte begränsas om inte roten är krossad. Rot squashing är där en exportprincipregel konfigureras där roten 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 squashing går du till menyn Exportera princip på volymen och ändrar sedan "Rotåtkomst" till "off" för principregeln.
Effekten av att inaktivera rotåtkomstrots squash till 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
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för