Chi può leggere un file in Windows: ACL, SID, proprietario ed ereditarietà

Quando Windows deve decidere se un utente può leggere un file, non si limita a controllare il nome dell’account: a fronte di semplice doppio clic, si attiva un sistema di autorizzazione composto da SID, gruppi, ACL, singole regole ACE, proprietario dell’oggetto ed ereditarietà delle autorizzazioni.

Troppe sigle? Sì. Abbiamo tuttavia a che fare con un meccanismo complesso che vale la pena conoscere per evitare di incocciare situazioni anomale e sapere come trarsi d’impaccio nei casi più difficili.

Un utente che non compare nelle autorizzazioni ma riesce comunque ad aprire il file; un amministratore che riceve “Accesso negato“; un file copiato che improvvisamente acquisisce permessi diversi; una cartella nella quale una regola “Nega” produce effetti apparentemente inattesi. Sono solo alcuni esempi che molti dei nostri lettori hanno certamente affrontato.

Il nome dell’account utente non ha valore: conta il SID

Il sistema operativo non basa il controllo degli accessi sui nomi degli account o sui gruppi a cui appartengono: Michele, Mario, Giovanni, Administrators, Users, SYSTEM, Authenticated Users e così via. Ogni account e gruppo è invece identificato mediante un Security Identifier o SID.

Un SID (così chiariamo subito il significato di uno degli acronimi citati in apertura…) può presentarsi, ad esempio, in una forma come la seguente:

S-1-5-21-1849505324-2179032556-3189257691-1001

Il nome dell’account può cambiare; il SID continua a rappresentare la stessa identità di sicurezza: rinominare un utente non equivale a creare un nuovo account.

Al momento del login da parte dell’utente, Windows costruisce un access token contenente il SID dell’utente e quelli dei gruppi applicabili alla sessione.

Quando un programma prova ad aprire un file, Windows confronta questi SID con le regole presenti nella DACL (Discretionary Access Control List), cioè l’elenco delle autorizzazioni associate al file. Ogni singola regola dell’elenco è una ACE (Access Control Entry) e stabilisce, per uno specifico utente o gruppo, quali operazioni sono consentite oppure negate. Windows verifica quali ACE si applicano all’utente che sta eseguendo il programma e decide se l’operazione richiesta, ad esempio leggere il file, può essere consentita.

Se una ACE concede il diritto a uno dei gruppi presenti nel token relativo all’utente, questi ha “semaforo verde” per procedere.

Ad esempio, una DACL che contiene BUILTIN\Users:(R) fa sì che ogni membro del gruppo Users possa beneficiare del permesso di lettura.

Come conoscere il SID dell’utente

Per vedere il SID dell’account utente in uso si può utilizzare il comando che segue:

whoami /user

Per visualizzare anche l’appartenenza ai gruppi:

whoami /groups

Questo secondo comando è spesso utile durante una diagnosi delle autorizzazioni. Se un utente riuscisse a leggere un file nonostante il proprio account non compaia nella DACL, uno dei primi controlli dovrebbe essere proprio basato sul comando whoami /groups. Una delle ACE potrebbe infatti riferirsi a un gruppo contenuto nel token di accesso.

Può capitare di trovare un’ACE simile a S-1-5-21-1849505324-2179032556-3189257691-1007:(R) senza che Windows mostri il nome dell’account. Allorquando il sistema operativo non riuscisse più a risolvere un SID verso un account conosciuto, mostra semplicemente il valore numerico.

Può succedere dopo l’eliminazione di un account locale, la reinstallazione di Windows, la rimozione di un utente Active Directory, il trasferimento delle unità da un altro computer, il ripristino di ACL provenienti da un’altra installazione.

ACL e ACE in Windows: differenze da conoscere

Una Access Control List (ACL) è un elenco di regole; ogni singola regola, come abbiamo visto in precedenza, è una ACE. Per un normale elemento memorizzato a livello di file system NTFS, chi conserva le autorizzazioni per l’accesso è – come abbiamo visto – la DACL.

Una ACE contiene essenzialmente:

• un SID;
• un insieme di diritti;
• il tipo della regola, ad esempio Allow oppure Deny;
• eventuali informazioni relative all’ereditarietà.

Immaginiamo una DACL strutturata come segue:

Michele Allow Read
Administrators Allow Full Control
Users Allow Read
Guest Deny Read

Cosa significa disporre del permesso di lettura

Il file system NTFS distingue diversi diritti “elementari”. Per un file esistono, tra gli altri, i seguenti:

FILE_READ_DATA
FILE_READ_ATTRIBUTES
FILE_READ_EA
FILE_EXECUTE
FILE_WRITE_DATA
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER

Il diritto FILE_READ_DATA consente di leggere i dati contenuti nel file, mentre READ_CONTROL permette di consultare le informazioni di sicurezza associate all’oggetto, ad esempio le autorizzazioni presenti nella DACL e il proprietario. WRITE_DAC consente invece di modificare la DACL.

L’interfaccia grafica di Windows aggrega questi diritti in combinazioni più comprensibili come Lettura, Lettura ed esecuzione, Modifica, Controllo completo. Quando si seleziona Lettura, Windows non salva quindi una semplice proprietà del tipo read=true: gestisce una maschera di diritti.

Il proprietario non è necessariamente chi può leggere il file

Uno degli equivoci più comuni trae vigore dalla confusione che si genera tra proprietà e autorizzazione all’accesso.

Ogni file o cartella protetti possiedono un owner, cioè un proprietario registrato nel security descriptor (struttura di sicurezza associata a un file o a una cartella che contiene informazioni come proprietario, DACL e regole di controllo degli accessi).

Nella situazione più comune, il proprietario coincide – almeno all’inizio – con il soggetto che ha creato l’oggetto. Essere proprietario, però, non significa automaticamente disporre di Controllo completo sui dati.

Il ruolo del proprietario è particolare soprattutto perché può modificare le autorizzazioni dell’oggetto: Microsoft sottolinea che il proprietario può cambiare le autorizzazioni anche quando l’accesso all’oggetto è altrimenti negato. “Diventare proprietario” di un file protetto non equivale all’acquisizione automatica dei permessi di lettura: spesso il passaggio successivo consiste nell’assegnarsi un’ACE che conceda il livello di accesso desiderato.

Nemmeno un amministratore può leggere tutto in Windows!

L’appartenenza al gruppo Administrators non implica che ogni processo possa ignorare le ACL dei file. Per questo motivo, un amministratore può ricevere il messaggio Accesso negato esattamente come un utente normale, sprovvisto di particolari diritti.

La differenza è che un amministratore dispone degli strumenti e dei privilegi necessari per assumere la proprietà dell’oggetto e modificarne successivamente le autorizzazioni.

Comandi come il seguente, permettono di intervenire sulla proprietà, ma non dovrebbero essere utilizzati indiscriminatamente su directory di sistema: modificare owner e ACL originali può rompere le aspettative di Windows, di servizi o applicazioni:

takeown /f "C:\Dati\documento.txt"

L’ereditarietà spiega gran parte delle ACL che vediamo sui file

Impostare manualmente le autorizzazioni di ogni singolo file sarebbe folle: per questo motivo, Windows si basa ampiamente sul meccanismo dell’ereditarietà. Un file o una sottocartella possono ricevere automaticamente ACE definite sulla directory superiore nella “gerarchia”. In altre parole, gli elementi memorizzati a livello di file system NTFS possono ereditare ACE dalla directory che li contiene.

Se D:\Documenti\ ha una ACE Gruppo-Utenti Allow Read configurata per propagarsi agli oggetti figli, creando D:\Documenti\manuale.pdf il nuovo file può ricevere automaticamente la stessa ACE.

L’ACL del file D:\Documenti\manuale.pdf può quindi apparire come Gruppo-Utenti:(I)(R) dove (I) indica che la voce è appunto ereditata (Inherited).

La configurazione delle autorizzazioni può essere amministrata principalmente sulle cartelle, lasciando a Windows il compito di propagare le ACE pertinenti agli oggetti figli.

Nulla vieta, ovviamente, che un file possa avere sia autorizzazioni proprie che autorizzazioni ereditate in qualità di oggetto figlio.

Copiare e spostare un file in Windows non sono operazioni equivalenti

Il tema dell’ereditarietà diventa particolarmente interessante quando i file sono trasferiti da una cartella all’altra: le autorizzazioni finali possono infatti dipendere dal tipo di operazione, dalla destinazione e dal file system coinvolto.

Un nuovo file creato all’interno di una certa cartella può ricevere il security descriptor previsto per quella posizione e le ACE ereditabili dalla cartella padre. Microsoft ricorda che le ACL predefinite sono assegnate quando viene creato un nuovo file o una nuova directory. Operazioni di ridenominazione o spostamento non equivalgono alla creazione di un nuovo oggetto.

Per questo, quando si diagnosticano autorizzazioni “misteriosamente cambiate” dopo copie, spostamenti, backup o ripristini, conviene verificare la DACL risultante invece di presumere che il file abbia necessariamente conservato tutte le ACE originarie.

Come vedere le autorizzazioni con icacls e interfaccia di Windows

Per controllare rapidamente le autorizzazioni di un file o di una cartella si può usare il comando di sistema icacls. Ad esempio, su una cartella reale del profilo utente:

icacls "%USERPROFILE%\Documents"

oppure su un file:

icacls "%USERPROFILE%\Desktop\acl-test.txt"

L’output può contenere righe simili a queste:

BUILTIN\Administrators:(F)
NT AUTHORITY\SYSTEM:(F)
BUILTIN\Users:(I)(RX)
PC\Michele:(M)

Le sigle principali sono F per Controllo completo, M per Modifica, RX per Lettura ed esecuzione e R per sola lettura. La marcatura (I) l’abbiamo già vista e conferma l’ereditarietà della ACE dalla cartella posta al livello superiore.

Nell’immagine compare anche il gruppo locale CodexSandboxUsers: viene creato da OpenAI Codex su Windows per assegnare permessi controllati ai processi eseguiti nella sandbox. Le sigle (OI) e (CI) indicano che la regola può propagarsi rispettivamente ai file e alle sottocartelle.

Cliccando con il tasto destro sul file o sulla cartella, quindi scegliendo Proprietà, Sicurezza, Avanzate, è possibile fare un confronto tra ciò che mostra l’interfaccia grafica e le singole ACE lette da icacls.

Come sapere se un utente può leggere o modificare un file

Leggere la DACL non sempre basta, perché un utente può ottenere le autorizzazioni attraverso più gruppi contemporaneamente.

Per verificare l’effettivo livello di accesso, suggeriamo di ricorrere alla comoda utilità AccessChk, piccolo programma della suite Microsoft Sysinternals pensato proprio per stabilire quali diritti possiede un determinato account su file, cartelle, servizi e altre risorse. Esempio:

accesschk Michele "C:\Users\Michele\Documents\acl-test.txt"

Aggiungendo l’opzione -v è possibile ottenere maggiori dettagli.

AccessChk calcola le autorizzazioni effettive tenendo conto dell’account e dei gruppi applicabili, evitando di dover interpretare manualmente tutte le ACE presenti nella DACL.

Dopo una reinstallazione Windows nega l’accesso ai vecchi file: perché succede e come risolvere

Una reinstallazione di Windows può creare una situazione apparentemente paradossale: si configura nuovamente un account con lo stesso nome usato in precedenza, ma alcuni file memorizzati nell’unità restituiscono comunque Accesso negato.

Come abbiamo spiegato in precedenza, la causa è l’uso del SID perché un account con lo stesso nome ha verosimilmente identificativo diverso dopo la reinstallazione del sistema.

Le ACL dei vecchi file possono continuare a contenere ACE riferite al SID precedente, che il nuovo account non può utilizzare: è possibile verificarlo con il comando
icacls. Se nell’output compare un SID non più associato a un nome utente, è probabile che appartenga alla precedente installazione di Windows.

Se si dispone dei necessari privilegi amministrativi, la soluzione consiste generalmente nell’assumere la proprietà del file o della cartella e assegnare poi al nuovo account le autorizzazioni necessarie:

takeown /f "D:\VecchiDocumenti" /r /d y
icacls "D:\VecchiDocumenti" /grant "%USERNAME%":(OI)(CI)F /t

Il primo comando assume la proprietà degli oggetti; il secondo concede all’utente corrente il controllo completo sulla cartella e sui suoi contenuti. Prima di applicare comandi ricorsivi è essenziale verificare attentamente la directory interessata: modificare in massa owner e ACL può alterare autorizzazioni dovrebbero essere mantenute.

Se si conosce il vecchio SID, icacls permette anche di cercare tutti i file e le cartelle che lo contengono nelle rispettive DACL: icacls "D:\VecchiDocumenti" /findsid S-1-5-21-.... è un modo molto rapido per individuare quali oggetti fanno ancora riferimento all’account della precedente installazione di Windows.

Una nota importante: le ACL proteggono l’accesso, non cifrano i dati

Le ACL prescrivono a Windows quali utenti e processi possono leggere, modificare o eliminare un oggetto. Se però un soggetto fosse in grado di accedere fisicamente al disco e leggere i dati con un ambiente che non applica quelle autorizzazioni, le ACL da sole non possono più svolgere il loro ruolo di “guardiani” del contenuto dei file.

Si pensi ad esempio a un sistema avviato a partire da un supporto di ripristino di Windows, ad esempio basato su Windows PE, da una distribuzione Linux live o addirittura dal supporto d’installazione di Windows. Per inciso, sapete che premendo MAIUSC+F10 o MAIUSC+Fn+F10 alla comparsa della schermata per la scelta della lingua si accede a un prompt dei comandi che permette l’accesso, senza limitazioni, all’intero contenuto del sistema? Con la possibilità, ad esempio, di copiare i file su un’unità esterna collegata al PC?

Il tutto se le unità disco non fossero protette con la cifratura: in questo caso, senza le chiavi appropriate – ad esempio la chiave di ripristino BitLocker – i dati restano illeggibili.

Per questo, quando l’obiettivo è proteggere le informazioni anche in caso di furto del computer o rimozione dell’unità, serve una tecnologia come BitLocker. ACL e BitLocker sono complementari: le prime regolano gli accessi all’interno di Windows; il secondo protegge i dati memorizzati sul supporto.