403 Errore di autorizzazione di accesso negato quando il bit adesivo è abilitato in ADLS Gen2
Questo articolo consente di comprendere il bit adesivo e fornisce informazioni su come controllare questa impostazione quando viene configurata in Azure Data Lake Storage (ADLS) Gen2 e ottenere problemi.
Qual è il bit adesivo in ADLS Gen2?
Gli utenti di ADLS Gen2 spesso devono gestire le autorizzazioni per utenti diversi e un modo per farlo consiste nell'usare un elenco di controllo di accesso (ACL). ACL è un sistema di controllo di accesso simile a POSIX con un'impostazione specifica denominata bit adesivo che può causare errori di autorizzazione. Per altre informazioni sulla modalità di controllo delle autorizzazioni e sul bit adesivo, vedere Elenchi di controllo di accesso (ACL) in Azure Data Lake Storage Gen2.
Il bit adesivo è una funzionalità avanzata che non è necessaria nell'impostazione ACL dell'account di archiviazione ADLS Gen2. È invece possibile usare la funzionalità maschera per limitare le autorizzazioni massime per gli utenti denominati, i gruppi denominati e il gruppo proprietario. Funziona in modo analogo al bit adesivo ed è facilmente configurabile nella portale di Azure.
403 Errore di autorizzazione negata dall'accesso
Considerare lo scenario descritto di seguito:
- Un account di archiviazione ADLS Gen2 ha un contenitore denominato contenitore e un percorso di cartella denominato cartella/cartella figlio.
- L'ACL viene usato come metodo di autorizzazione.
- Nell'impostazione ACL dell'account di archiviazione ADLS Gen2 si è configurati con l'autorizzazione Esegui (X) per la directory e la cartella radice e con l'autorizzazione Scrittura ed esecuzione (WX) per la cartella figlio.
- Il bit adesivo è abilitato nella cartella figlio.
- Si tenta di creare o caricare un nuovo file, ad esempiotest.txt, nel contenitore/cartella/cartella figlio dell'account di archiviazione ADLS Gen2.You try to create or upload a new file, example, test.txt, into the ADLS Gen2 Storage Account folder container/folder/child-folder/.
In questo scenario viene visualizzato un errore di autorizzazione accesso negato 403.
Questo errore si verifica per due motivi:
- Non si dispone di autorizzazioni sufficienti per accedere al percorso della cartella.
- Si dispone di autorizzazioni sufficienti, ma l'abilitazione del bit adesivo fa sì che non si sia proprietari di questo percorso di cartella.
Identificare se il bit adesivo causa un errore di accesso negato 403
Verificare l'impostazione ACL della cartella e delle cartelle padre e quindi confrontarla con gli scenari comuni correlati alle autorizzazioni ACL. Se le autorizzazioni sono sufficienti, l'errore 403 potrebbe essere causato dal bit adesivo.
Verificare l'impostazione del bit adesivo usando l'interfaccia della riga di comando di Azure
Esistono molti modi per controllare questa impostazione, ad esempio una chiamata api REST, un comando di PowerShell e l'interfaccia della riga di comando di Azure. È consigliabile usare l'opzione dell'interfaccia della riga di comando di Azure perché non richiede l'installazione di software aggiuntivo e il comando è facile da comprendere.
Per verificare l'impostazione del bit permanente usando l'interfaccia della riga di comando di Azure, seguire questa procedura:
Accedere al portale di Azure con l'account. Assicurarsi che questo account disponga dell'assegnazione del ruolo Proprietario dei dati dei BLOB di archiviazione nell'account di archiviazione ADLS Gen2.
Seleziona Cloud Shell dal portale di Azure.
Usare il comando seguente per ottenere l'ACL e l'impostazione a bit costante della directory contenitore/cartella :
az storage fs access show -p folder -f container --account-name account --auth-mode loginPer controllare l'ACL e l'impostazione del bit adesivo della directory radice, ovvero l'ACL a livello di contenitore e l'impostazione del bit adesivo, usare il comando seguente:
az storage fs access show -p / -f container --account-name account --auth-mode loginEcco un output di esempio:
Nel corpo JSON della risposta concentrarsi su
permissions. In genere contiene 9 o 10 bit con un simbolo "+" aggiuntivo. Per altre informazioni su queste lettere, vedere Utenti e identità.L'esempio precedente indica che tutte le autorizzazioni utente sono abilitate e che il bit adesivo è abilitato. Per altre informazioni su come leggere questa notazione di autorizzazione, vedere Notazione delle autorizzazioni Unix tradizionali.
La nona lettera ha quattro valori possibili: "-", "x", "t" e "T". Se il valore di questa lettera è "t" o "T", significa che il bit adesivo è abilitato. "t" è "x" con il bit adesivo abilitato e "T" è "-" con il bit adesivo abilitato.
"rwxrwxrwt" può essere spiegato come segue:
- Le autorizzazioni r,w e x sono abilitate per il proprietario.
- Le autorizzazioni r,w e x sono abilitate per il gruppo Proprietario.
- Le autorizzazioni r,w e x sono abilitate per altri utenti e il bit adesivo è abilitato.
Per comprenderlo meglio, ecco un altro esempio per "rwxr-xr-T":
- Le autorizzazioni r,w e x sono abilitate per il proprietario.
- Le autorizzazioni r e x sono abilitate per il gruppo Proprietario.
- Solo l'autorizzazione r è abilitata per altri utenti e il bit adesivo è abilitato.
In base ai moduli brevi per le autorizzazioni, l'autorizzazione per i moduli brevi viene calcolata per ogni gruppo di tre lettere ("r" come 4, "w" come 2 e "x "as 1). Quindi, "rw-rwx--x" sarà uguale a 4+2+0, 4+2+1, 0+0+1, 671. In base a questa regola di calcolo, è sufficiente aggiungere la quarta lettera all'inizio. Se il bit adesivo è abilitato, impostarlo su 1. Se il bit adesivo è disabilitato, impostarlo su 0.
Ecco alcuni esempi:
- rwxrwxrwt => 1777
- rwxr-xr-T => 1754
- rw-rwx--x => 0671
Disabilitare/abilitare l'impostazione del bit adesivo
Per disabilitare/abilitare l'impostazione del bit permanente, impostare le autorizzazioni sui valori previsti.
L'account di Azure usato per modificare questa impostazione deve avere il ruolo Proprietario dati BLOB di archiviazione nell'account di archiviazione ADLS Gen2 di destinazione. Esistono molti modi possibili per modificare l'impostazione del bit adesivo. Ecco gli SDK supportati:
Ecco un esempio di disabilitazione/abilitazione dell'impostazione del bit permanente con l'interfaccia della riga di comando di Azure.
Accedere al portale di Azure con l'account con l'assegnazione del ruolo Proprietario dati BLOB di archiviazione nell'account di archiviazione ADLS Gen2 di destinazione.
Seleziona Cloud Shell dal portale di Azure.
Per impostare l'ACL e l'impostazione di bit sticky della directory contenitore/cartella sulle autorizzazioni "rwxrwxrwt" e per abilitare il bit adesivo, usare il comando seguente:
az storage fs access set --permissions rwxrwxrwt -p folder -f container --account-name account --auth-mode loginPer modificare l'impostazione della directory radice, ovvero l'ACL a livello di contenitore e l'impostazione del bit permanente, usare il comando seguente:
az storage fs access set --permissions rwxrwxrwt -p / -f container --account-name account --auth-mode loginL'oggetto
{permission notation}nel comando precedente può accettare notazioni di tipo long e short form. Ciò significa che anche il comando seguente è qualificato:az storage fs access set --permissions 1776 -p folder -f container --account-name account --auth-mode loginEcco un output di esempio:
Contattaci per ricevere assistenza
In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.