403 Errore di autorizzazione di accesso negato quando il bit permanente è abilitato in ADLS Gen2
Questo articolo illustra il bit permanente e fornisce informazioni su come controllare questa impostazione quando la si configura in Azure Data Lake Storage (ADLS) Gen2 e si verificano problemi.
Qual è il bit permanente in ADLS Gen2?
Gli utenti di ADLS Gen2 spesso devono gestire le autorizzazioni per utenti diversi e un modo per eseguire questa operazione 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 sticky che può causare errori di autorizzazione. Per altre informazioni sulla modalità di controllo delle autorizzazioni e sul bit permanente, vedere Elenchi di controllo di accesso (ACL) in Azure Data Lake Storage Gen2.
Il bit permanente è 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. Questo funziona in modo analogo al bit appiccicoso ed è facilmente configurato nella portale di Azure.
403 Errore di autorizzazione negata per l'accesso
Prendi in considerazione lo scenario seguente:
- Un account di archiviazione ADLS Gen2 ha un contenitore denominato contenitore e un percorso di cartella denominato cartella/cartella figlio.
- L'elenco di controllo di accesso viene usato come metodo di autorizzazione.
- Nell'impostazione ACL dell'account di archiviazione DILS Gen2, si è configurata con l'autorizzazione Execute (X) per la directory radice e la cartella e con l'autorizzazione Write and Execute (WX) per la cartella figlio.
- Il bit sticky è abilitato nella cartella figlio.
- Si tenta di creare o caricare un nuovo file, ad esempio test.txt, nel contenitore/cartella-cartella/cartella/cartella dell'account di archiviazione di ADLS Gen2.
In questo scenario viene visualizzato un errore di autorizzazione di 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 sticky fa sì che non sia il proprietario di questo percorso della cartella.
Identificare se il bit sticky 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 sticky.
Verificare l'impostazione di bit permanente 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 un'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 di bit permanente tramite l'interfaccia della riga di comando di Azure, seguire questa procedura:
Accedere al portale di Azure con il proprio account. Assicurarsi che questo account abbia l'assegnazione di ruolo Proprietario dati 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 di bit permanente 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 di bit permanente della directory radice, ovvero l'ACL a livello di contenitore e l'impostazione del bit permanente, usare il comando seguente:
az storage fs access show -p / -f container --account-name account --auth-mode loginDi seguito è riportato un output di esempio:
Nel corpo JSON della risposta concentrarsi su
permissions. Normalmente 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 permanente è 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 sticky è abilitato. "t" è "x" con il bit sticky abilitato e "T" è "-" con il bit sticky 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 permanente è 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 permanente è abilitato.
In base ai moduli brevi per le autorizzazioni, l'autorizzazione di forma breve 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 sticky è abilitato, impostarlo su 1. Se il bit sticky è disabilitato, impostarlo su 0.
Di seguito sono riportati alcuni esempi.
- rwxrwxrwt => 1777
- rwxr-xr-T => 1754
- rw-rwx--x => 0671
Disabilitare/Abilitare l'impostazione di bit permanente
Per disabilitare/abilitare l'impostazione di bit permanente, impostare le autorizzazioni sui valori previsti.
L'account 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 dei bit permanenti. Ecco gli SDK supportati:
Ecco un esempio di disabilitazione/abilitazione dell'impostazione di bit permanente con l'interfaccia della riga di comando di Azure.
Accedere al portale di Azure con l'account con l'assegnazione di 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 dei bit permanenti della directory contenitore/cartella sulle autorizzazioni "rwxrwxrwt" e per abilitare il bit permanente, 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 sia le notazioni long che 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.