Åtkomstkontrollistor (ACL:er) för Azure Data Lake Storage

Artikel
06/06/2024

Azure Data Lake Storage implementerar en åtkomstkontrollmodell som stöder både rollbaserad åtkomstkontroll i Azure (Azure RBAC) och POSIX-liknande åtkomstkontrollistor (ACL). Den här artikeln beskriver åtkomstkontrollistor i Data Lake Storage. Mer information om hur du införlivar Azure RBAC tillsammans med ACL:er och hur systemet utvärderar dem för att fatta auktoriseringsbeslut finns i Åtkomstkontrollmodell i Azure Data Lake Storage.

Om ACL:er

Du kan associera ett säkerhetsobjekt med en åtkomstnivå för filer och kataloger. Varje association registreras som en post i en åtkomstkontrollista (ACL). Varje fil och katalog i ditt lagringskonto har en åtkomstkontrollista. När ett säkerhetsobjekt försöker utföra en åtgärd på en fil eller katalog avgör en ACL-kontroll om säkerhetsobjektet (användare, grupp, tjänstens huvudnamn eller hanterade identitet) har rätt behörighetsnivå för att utföra åtgärden.

Kommentar

ACL:er gäller endast för säkerhetsobjekt i samma klientorganisation. ACL:er gäller inte för användare som använder auktorisering av delad nyckel eftersom ingen identitet är associerad med anroparen och därför kan behörighetsbaserad behörighetsbaserad auktorisering för säkerhetsobjekt inte utföras. Detsamma gäller för SAS-token (signatur för delad åtkomst), förutom när en användardelegering av SAS-token används. I så fall utför Azure Storage en POSIX ACL-kontroll mot objekt-ID:t innan åtgärden godkänns så länge den valfria parametern suoid används. Mer information finns i Skapa en SAS för användardelegering.

Så här ställer du in ACL:er

Information om hur du anger behörigheter på fil- och katalognivå finns i någon av följande artiklar:

Miljö	Artikel
Azure Storage Explorer	Använda Azure Storage Explorer för att hantera ACL:er i Azure Data Lake Storage
Azure Portal	Använd Azure Portal för att hantera ACL:er i Azure Data Lake Storage
.NET	Använda .NET för att hantera ACL:er i Azure Data Lake Storage
Java	Använda Java för att hantera ACL:er i Azure Data Lake Storage
Python	Använda Python för att hantera ACL:er i Azure Data Lake Storage
JavaScript (Node.js)	Använda JavaScript SDK i Node.js för att hantera ACL:er i Azure Data Lake Storage
PowerShell	Använda PowerShell för att hantera ACL:er i Azure Data Lake Storage
Azure CLI	Använda Azure CLI för att hantera ACL:er i Azure Data Lake Storage
REST-API	Sökväg – Uppdatera

Viktigt!

Om säkerhetsobjektet är ett huvudnamn för tjänsten är det viktigt att använda objekt-ID:t för tjänstens huvudnamn och inte objekt-ID:t för den relaterade appregistreringen. Om du vill hämta objekt-ID:t för tjänstens huvudnamn öppnar du Azure CLI och använder sedan det här kommandot: az ad sp show --id <Your App ID> --query objectId. Ersätt <Your App ID> platshållaren med app-ID:t för din appregistrering. Tjänstens huvudnamn behandlas som en namngiven användare. Du lägger till det här ID:t i ACL:en på samma sätt som vilken namngiven användare som helst. Namngivna användare beskrivs senare i den här artikeln.

Typer av ACL:er

Det finns två typer av åtkomstkontrollistor: åtkomst-ACL:er och standard-ACL:er.

Åtkomst-ACL:er kontrollerar åtkomst till ett objekt. Filer och kataloger har båda åtkomst-ACL:er.

Standard-ACL:er är mallar med ACL:er som är associerade med en katalog som fastställer åtkomst-ACL:er för alla underordnade objekt som skapas under katalogen. Filer har inte standard-ACL:er.

Både åtkomst-ACL:er och standard-ACL:er har samma struktur.

Kommentar

Att ändra standard-ACL på ett överordnat objekt påverkar inte åtkomst-ACL eller standard-ACL för underordnade objekt som redan finns.

Behörighetsnivåer

Behörigheterna för kataloger och filer i en container är Läs, Skriv och Kör, och de kan användas på filer och kataloger enligt följande tabell:

	Fil	Katalog
Läsa (R)	Kan läsa innehållet i en fil	Kräver läsning och körning för att visa innehållet i katalogen
Skriva (W)	Kan skriva eller lägg till i en fil	Kräver skrivning och körning för att skapa underordnade objekt i en katalog
Köra (X)	Betyder inte något i samband med Data Lake Storage	Krävs för att bläddra i underordnade objekt i en katalog

Kommentar

Om du beviljar behörigheter genom att endast använda ACL:er (ingen Azure RBAC) måste du ge säkerhetsobjektet läs- eller skrivbehörighet till en fil genom att ge säkerhetsobjektet körbehörighet till rotmappen i containern och till varje mapp i hierarkin med mappar som leder till filen.

Kortformat för behörigheter

RWXanvänds för att ange läsa + skriva + köra. Ett numeriskt mer komprimerat format finns där Läsa = 4, skriva = 2 och Köra = 1 och deras summa representerar behörigheterna. Här följer några exempel.

Numeriskt format	Kortformat	Vad det innebär
7	`RWX`	Läsa + skriva + köra
5	`R-X`	Läsa + köra
4	`R--`	Lästa
0	`---`	Inga behörigheter

Arv av behörigheter

I POSIX-modellen som används av Data Lake Storage lagras behörigheter för ett objekt på själva objektet. Det innebär att behörigheter för ett objekt inte kan ärvas från de överordnade objekten om behörigheterna anges efter att det underordnade objektet redan har skapats. Behörigheter ärvs endast om standardbehörigheter har angetts för de överordnade objekten innan de underordnade objekten har skapats.

I följande tabell visas de ACL-poster som krävs för att aktivera ett säkerhetsobjekt för att utföra de åtgärder som anges i kolumnen Åtgärd .

Den här tabellen visar en kolumn som representerar varje nivå i en fiktiv kataloghierarki. Det finns en kolumn för rotkatalogen för containern (/), en underkatalog med namnet Oregon, en underkatalog till Oregon-katalogen med namnet Portland och en textfil i Portland-katalogen med namnet Data.txt.

Viktigt!

Den här tabellen förutsätter att du endast använder ACL:er utan några Azure-rolltilldelningar. En liknande tabell som kombinerar Azure RBAC tillsammans med ACL:er finns i tabellen Behörigheter: Kombinera Azure RBAC, ABAC och ACL:er.

Åtgärd	/	Oregon/	Portland/	Data.txt
Läs Data.txt	`--X`	`--X`	`--X`	`R--`
Lägg till i Data.txt	`--X`	`--X`	`--X`	`RW-`
Ta bort Data.txt	`--X`	`--X`	`-WX`	`---`
Ta bort /Oregon/	`-WX`	`RWX`	`RWX`	`---`
Ta bort /Oregon/Portland/	`--X`	`-WX`	`RWX`	`---`
Skapa Data.txt	`--X`	`--X`	`-WX`	`---`
Lista/	`R-X`	`---`	`---`	`---`
Lista /Oregon/	`--X`	`R-X`	`---`	`---`
Lista /Oregon/Portland/	`--X`	`--X`	`R-X`	`---`

Ta bort filer och kataloger

Som du ser i föregående tabell krävs inte skrivbehörigheter för filen för att ta bort den så länge katalogbehörigheterna har angetts korrekt. Men om du vill ta bort en katalog och allt dess innehåll måste den överordnade katalogen ha skriv- och körningsbehörigheter. Katalogen som ska tas bort och alla kataloger i den kräver läs- och skrivbehörigheter och körningsbehörigheter.

Kommentar

Rotkatalogen "/" kan aldrig tas bort.

Användare och identiteter

Varje fil och katalog har olika behörigheter för dessa identiteter:

Ägande användare
Ägande grupp
Namngivna användare
Namngivna grupper
Namngivna tjänstens huvudnamn
Namngivna hanterade identiteter
Alla andra användare

Identiteterna för användare och grupper är Microsoft Entra-identiteter. Så om inget annat anges kan en användare, i samband med Data Lake Storage, referera till en Microsoft Entra-användare, tjänstens huvudnamn, hanterad identitet eller säkerhetsgrupp.

Superanvändaren

En superanvändare har flest rättigheter av alla användare. En superanvändare:

Har RWX-behörigheter till alla filer och mappar.
Kan ändra behörigheterna för alla filer och mappar.
Kan ändra ägande användare eller ägande grupp för alla filer och mappar.

Om en container, fil eller katalog skapas med hjälp av delad nyckel, ett konto-SAS eller en Tjänst-SAS anges ägar- och ägargruppen till $superuser.

Ägande användare

Användaren som skapade objektet är automatiskt ägande användare för objektet. En ägande användare kan:

Ändra behörigheterna för en fil som ägs.
Ändra ägande grupp för en fil som ägs, så länge den ägande användaren också är medlem i målgruppen.

Kommentar

Den ägande användaren kan inte ändra den ägande användaren av en fil eller katalog. Endast superanvändare kan ändra ägande användare av en fil eller katalog.

Ägande grupp

I POSIX-ACL:er är varje användare associerad med en primär grupp. Användaren "Alice" kan till exempel tillhöra gruppen "finance". Alice kan också tillhöra flera grupper, men en grupp har alltid angetts som deras primära grupp. När Alice skapar en fil i POSIX är den ägande gruppen för filen inställd på hennes primära grupp, som i det här fallet är "ekonomi". Den ägande gruppen fungerar annars på samma sätt som tilldelade behörigheter för andra användare/grupper.

Tilldela ägande grupp för en ny fil eller katalog

Fall 1: Rotkatalogen /. Den här katalogen skapas när en Data Lake Storage-container skapas. I det här fallet är ägandegruppen inställd på den användare som skapade containern om den gjordes med OAuth. Om containern skapas med hjälp av delad nyckel, ett konto-SAS eller en tjänst-SAS anges ägar- och ägargruppen till $superuser.
Ärende 2 (alla andra fall): När ett nytt objekt skapas kopieras den ägande gruppen från den överordnade katalogen.

Ändra ägande grupp

Den ägande gruppen kan ändras av:

Alla superanvändare.
Den ägande användaren, om den ägande användaren också är medlem i målgruppen.

Kommentar

Ägande gruppen kan inte ändra ACL:er för en fil eller katalog. Även om ägandegruppen är inställd på den användare som skapade kontot när det gäller rotkatalogen, ärende 1 ovan, är ett enskilt användarkonto inte giltigt för att ge behörigheter via den ägande gruppen. Du kan tilldela den här behörigheten till en giltig användargrupp, om det är lämpligt.

Så här utvärderas behörigheter

Identiteter utvärderas i följande ordning:

Superanvändare
Ägande användare
Namngiven användare, tjänstens huvudnamn eller hanterade identitet
Ägande grupp eller namngiven grupp
Alla andra användare

Om mer än en av dessa identiteter gäller för ett säkerhetsobjekt beviljas den behörighetsnivå som är associerad med den första identiteten. Om ett säkerhetsobjekt till exempel både är den ägande användaren och en namngiven användare gäller behörighetsnivån som är associerad med den ägande användaren.

Namngivna grupper betraktas alla tillsammans. Om ett säkerhetsobjekt är medlem i mer än en namngiven grupp utvärderar systemet varje grupp tills den önskade behörigheten har beviljats. Om ingen av de namngivna grupperna ger önskad behörighet går systemet vidare för att utvärdera en begäran mot den behörighet som är associerad med alla andra användare.

Följande pseudokod representerar algoritmen för åtkomstkontroll för lagringskonton. Den här algoritmen visar i vilken ordning identiteterna utvärderas.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

Masken

Som du ser i algoritmen för åtkomstkontroll begränsar masken åtkomsten för namngivna användare, ägande grupp och namngivna grupper.

För en ny Data Lake Storage-container är masken för åtkomst-ACL för rotkatalogen ("/") som standard 750 för kataloger och 640 för filer. I följande tabell visas den symboliska notationen för dessa behörighetsnivåer.

Enhet	Directories	Filer
Ägande användare	`rwx`	`rw-`
Ägande grupp	`r-x`	`r--`
Övrigt	`---`	`---`

Filer får inte X-biten eftersom den är irrelevant för filer i ett system med endast lagring.

Masken kan anges per anrop. Detta gör att olika användningssystem, till exempel kluster, kan ha olika effektiva masker för sina filåtgärder. Om en mask anges för en viss begäran åsidosätter den helt standardmasken.

Sticky bit

Den klibbiga biten är en mer avancerad funktion i en POSIX-container. När det gäller Data Lake Storage är det osannolikt att den klibbiga biten kommer att behövas. Sammanfattningsvis kan ett underordnat objekt bara tas bort eller byta namn på det underordnade objektets ägande användare, katalogens ägare eller Superuser ($superuser).

Den klibbiga biten visas inte i Azure Portal. Mer information om den klibbiga biten och hur du ställer in den finns i Vad är den klibbiga biten Data Lake Storage?.

Standardbehörigheter för nya filer och kataloger

När en ny fil eller katalog skapas under en befintlig katalog, anger standard-ACL:en på den överordnade katalogen:

Den underordnade katalogens standard-ACL och åtkomst-ACL.
Den underordnade filens åtkomst-ACL (filer har ingen standard-ACL).

umask

När du skapar en standard-ACL tillämpas umask på åtkomst-ACL för att fastställa de första behörigheterna för en standard-ACL. Om en standard-ACL definieras i den överordnade katalogen ignoreras umasken effektivt och standard-ACL för den överordnade katalogen används för att definiera dessa initiala värden i stället.

umasken är ett 9-bitars värde på överordnade kataloger som innehåller ett RWX-värde för ägande användare, ägande grupp och annat.

Umask för Azure Data Lake Storage ett konstant värde som är inställt på 007. Det här värdet översätts till:

umask-komponent	Numeriskt format	Kortformat	Innebörd
umask.owning_user	0	`---`	För ägande användare kopierar du den överordnade åtkomst-ACL:en till den underordnade acl:ens standard-ACL
umask.owning_group	0	`---`	För ägande grupp kopierar du den överordnade åtkomst-ACL:en till det underordnades standard-ACL
umask.other	7	`RWX`	För övrigt tar du bort alla behörigheter för den underordnade åtkomst-ACL:en

Vanliga frågor

Måste jag aktivera stöd för ACL:er?

Nej. Åtkomstkontroll via ACL:er är aktiverad för ett lagringskonto så länge funktionen Hierarkisk namnrymd (HNS) är aktiverad.

Om HNS är inaktiverat gäller fortfarande Azure RBAC-auktoriseringsreglerna.

Vilket är det bästa sättet att tillämpa ACL:er?

Använd alltid Microsoft Entra-säkerhetsgrupper som det tilldelade huvudkontot i en ACL-post. Motstå möjligheten att tilldela enskilda användare eller tjänstens huvudnamn direkt. Med denna struktur kan du lägga till och ta bort användare eller tjänstens huvudnamn utan att behöva tillämpa ACL:er på en hel katalogstruktur igen. I stället kan du bara lägga till eller ta bort användare och tjänstens huvudnamn från lämplig Microsoft Entra-säkerhetsgrupp.

Det finns många olika sätt att konfigurera grupper. Anta till exempel att du har en katalog med namnet /LogData som innehåller loggdata som genereras av servern. Azure Data Factory (ADF) matar in data i den mappen. Specifika användare från tjänstutvecklingsteamet laddar upp loggar och hanterar andra användare av den här mappen, och olika Databricks-kluster analyserar loggar från den mappen.

Om du vill aktivera dessa aktiviteter kan du skapa en LogsWriter grupp och en LogsReader grupp. Sedan kan du tilldela behörigheter på följande sätt:

LogsWriter Lägg till gruppen i ACL:en för katalogen /LogData med rwx behörigheter.
LogsReader Lägg till gruppen i ACL:en för katalogen /LogData med r-x behörigheter.
Lägg till tjänstens huvudnamnsobjekt eller hanterad tjänstidentitet (MSI) för ADF i LogsWriters gruppen.
Lägg till användare i serviceteknikteamet i LogsWriter gruppen.
Lägg till objektet för tjänstens huvudnamn eller MSI för Databricks i LogsReader gruppen.

Om en användare i serviceteknikteamet lämnar företaget kan du bara ta bort dem från LogsWriter gruppen. Om du inte lade till den användaren i en grupp, utan i stället lade till en dedikerad ACL-post för den användaren, måste du ta bort den ACL-posten från katalogen /LogData . Du måste också ta bort posten från alla underkataloger och filer i hela kataloghierarkin i katalogen /LogData .

Information om hur du skapar en grupp och lägger till medlemmar finns i Skapa en grundläggande grupp och lägg till medlemmar med hjälp av Microsoft Entra-ID.

Viktigt!

Azure Data Lake Storage Gen2 är beroende av Microsoft Entra-ID för att hantera säkerhetsgrupper. Microsoft Entra ID rekommenderar att du begränsar gruppmedlemskap för ett visst säkerhetsobjekt till mindre än 200. Den här rekommendationen beror på en begränsning av JSON-webbtoken (JWT) som tillhandahåller information om säkerhetsobjektets gruppmedlemskap i Microsoft Entra-program. Om du överskrider den här gränsen kan det leda till oväntade prestandaproblem med Data Lake Storage Gen2. Mer information finns i Konfigurera gruppanspråk för program med hjälp av Microsoft Entra-ID.

Hur utvärderas Azure RBAC- och ACL-behörigheter?

Information om hur systemet utvärderar Azure RBAC och ACL:er tillsammans för att fatta auktoriseringsbeslut för lagringskontoresurser finns i Så utvärderas behörigheter.

Vilka är gränserna för Azure-rolltilldelningar och ACL-poster?

Följande tabell innehåller en sammanfattning av de gränser som du bör överväga när du använder Azure RBAC för att hantera "grova" behörigheter (behörigheter som gäller för lagringskonton eller containrar) och hur du använder ACL:er för att hantera "detaljerade" behörigheter (behörigheter som gäller för filer och kataloger). Använd säkerhetsgrupper för ACL-tilldelningar. Genom att använda grupper är det mindre troligt att du överskrider det maximala antalet rolltilldelningar per prenumeration och det maximala antalet ACL-poster per fil eller katalog.

Mekanism	Omfattning	Gränser	Behörighetsnivå som stöds
Azure RBAC	Lagringskonton, containrar. Azure-rolltilldelningar mellan resurser på prenumerations- eller resursgruppsnivå.	4000 Azure-rolltilldelningar i en prenumeration	Azure-roller (inbyggda eller anpassade)
ACL	Katalog, fil	32 ACL-poster (i praktiken 28 ACL-poster) per fil och per katalog. Åtkomst- och standard-ACL:er har varsin gräns på 32 ACL.	ACL-behörighet

Stöder Data Lake Storage arv av Azure RBAC?

Azure-rolltilldelningar ärver. Tilldelningar flödar från prenumerations-, resursgrupps- och lagringskontoresurser ned till containerresursen.

Stöder Data Lake Storage arv av ACL:er?

Standard-ACL:er kan användas för att ange ACL:er för nya underordnade underkataloger och filer som skapats under den överordnade katalogen. Om du vill uppdatera ACL:er för befintliga underordnade objekt måste du lägga till, uppdatera eller ta bort ACL:er rekursivt för den önskade kataloghierarkin. Vägledning finns i avsnittet Så här anger du ACL:er i den här artikeln.

Vilka behörigheter krävs för att rekursivt ta bort en katalog och dess innehåll?

Anroparen har behörigheten "superanvändare"

Eller

Den överordnade katalogen måste ha behörigheten Skriv + Kör.
Katalogen som ska tas bort och alla kataloger i den kräver läs- och skrivbehörigheter och körningsbehörigheter.

Kommentar

Du behöver inte skrivbehörighet för att ta bort filer i kataloger. Dessutom kan rotkatalogen "/" aldrig tas bort.

Vem äger en fil eller katalog?

Skaparen av en fil eller katalog blir ägare. När det gäller rotkatalogen är detta identiteten för den användare som skapade containern.

Vilken grupp anges som ägande grupp för en fil eller katalog när den skapas?

Den ägande gruppen kopieras från den ägande gruppen i den överordnade katalogen under vilken den nya filen eller katalogen skapas.

Jag äger en fil men jag har inte de RWX-behörigheter jag behöver. Vad ska jag göra?

Den ägande användaren kan lätt ändra behörigheterna för filen för att ge sig själva de RWX-behörigheter de behöver.

Varför kan jag ibland se GUID:er i ACL:er?

Ett GUID visas om posten representerar en användare och den användaren inte längre finns i Microsoft Entra. Detta inträffar vanligtvis när användaren har lämnat företaget eller om deras konto har tagits bort i Microsoft Entra-ID. Dessutom har tjänstens huvudnamn och säkerhetsgrupper inte något UPN (User Principal Name) för att identifiera dem och representeras därför av deras OID-attribut (ett guid). Om du vill rensa ACL:er tar du bort dessa GUID-poster manuellt.

Hur anger jag ACL:er korrekt för ett huvudnamn för tjänsten?

När du definierar ACL:er för tjänstens huvudnamn är det viktigt att använda objekt-ID (OID) för tjänstens huvudnamn för appregistreringen som du skapade. Observera att registrerade appar har ett separat huvudnamn för tjänsten i den specifika Microsoft Entra-klientorganisationen. Registrerade appar har en OID som visas i Azure Portal, men tjänstens huvudnamn har en annan (annan) OID. Artikel Om du vill hämta OID för tjänstens huvudnamn som motsvarar en appregistrering kan du använda az ad sp show kommandot . Ange Program-ID som parameter. Här är ett exempel på hur du hämtar OID för tjänstens huvudnamn som motsvarar en appregistrering med app-ID = ffffffffff-eeee-dddd-cccc-bbbbbbbbbbbbb0. Kör följande kommando i Azure CLI:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

OID kommer att visas.

När du har rätt OID för tjänstens huvudnamn går du till sidan Hantera åtkomst i Storage Explorer för att lägga till OID och tilldela lämpliga behörigheter för OID. Se till att du väljer Spara

Kan jag ange ACL för en container?

Nej. En container har ingen ACL. Du kan dock ange ACL för containerns rotkatalog. Varje container har en rotkatalog och delar samma namn som containern. Om containern till exempel heter my-containerheter rotkatalogen my-container/.

Rest-API:et för Azure Storage innehåller en åtgärd med namnet Ange container-ACL, men den åtgärden kan inte användas för att ange ACL för en container eller rotkatalogen för en container. I stället används den åtgärden för att ange om blobar i en container kan nås med en anonym begäran. Vi rekommenderar att du kräver auktorisering för alla begäranden till blobdata. Mer information finns i Översikt: Åtgärda anonym läsåtkomst för blobdata.

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?

Se även

Åtkomstkontrollmodell i Azure Data Lake Storage

Dela via

Åtkomstkontrollistor (ACL:er) för Azure Data Lake Storage

Om ACL:er

Så här ställer du in ACL:er

Typer av ACL:er

Behörighetsnivåer

Kortformat för behörigheter

Arv av behörigheter

Ta bort filer och kataloger

Användare och identiteter

Superanvändaren

Ägande användare

Ägande grupp

Tilldela ägande grupp för en ny fil eller katalog

Ändra ägande grupp

Så här utvärderas behörigheter

Masken

Sticky bit

Standardbehörigheter för nya filer och kataloger

umask

Vanliga frågor

Måste jag aktivera stöd för ACL:er?

Vilket är det bästa sättet att tillämpa ACL:er?

Hur utvärderas Azure RBAC- och ACL-behörigheter?

Vilka är gränserna för Azure-rolltilldelningar och ACL-poster?

Stöder Data Lake Storage arv av Azure RBAC?

Stöder Data Lake Storage arv av ACL:er?

Vilka behörigheter krävs för att rekursivt ta bort en katalog och dess innehåll?

Vem äger en fil eller katalog?

Vilken grupp anges som ägande grupp för en fil eller katalog när den skapas?

Jag äger en fil men jag har inte de RWX-behörigheter jag behöver. Vad ska jag göra?

Varför kan jag ibland se GUID:er i ACL:er?

Hur anger jag ACL:er korrekt för ett huvudnamn för tjänsten?

Kan jag ange ACL för en container?

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?

Se även

Feedback

Ytterligare resurser

Dela via

Åtkomstkontrollistor (ACL:er) för Azure Data Lake Storage

Om ACL:er

Så här ställer du in ACL:er

Typer av ACL:er

Behörighetsnivåer

Kortformat för behörigheter

Arv av behörigheter

Vanliga scenarier som rör ACL-behörigheter

Ta bort filer och kataloger

Användare och identiteter

Superanvändaren

Ägande användare

Ägande grupp

Tilldela ägande grupp för en ny fil eller katalog

Ändra ägande grupp

Så här utvärderas behörigheter

Masken

Sticky bit

Standardbehörigheter för nya filer och kataloger

umask

Vanliga frågor

Måste jag aktivera stöd för ACL:er?

Vilket är det bästa sättet att tillämpa ACL:er?

Hur utvärderas Azure RBAC- och ACL-behörigheter?

Vilka är gränserna för Azure-rolltilldelningar och ACL-poster?

Stöder Data Lake Storage arv av Azure RBAC?

Stöder Data Lake Storage arv av ACL:er?

Vilka behörigheter krävs för att rekursivt ta bort en katalog och dess innehåll?

Vem äger en fil eller katalog?

Vilken grupp anges som ägande grupp för en fil eller katalog när den skapas?

Jag äger en fil men jag har inte de RWX-behörigheter jag behöver. Vad ska jag göra?

Varför kan jag ibland se GUID:er i ACL:er?

Hur anger jag ACL:er korrekt för ett huvudnamn för tjänsten?

Kan jag ange ACL för en container?

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?

Se även

Feedback

Ytterligare resurser