Funzionamento di AccessCheck

Quando un thread tenta di accedere a un oggetto a protezione diretta, il sistema concede o nega l'accesso. Se l'oggetto non ha un elenco di controllo di accesso discrezionale (DACL), il sistema concede l'accesso; in caso contrario, il sistema cerca Controllo di accesso voci (ACL) dell'oggetto che si applicano al thread. Ogni ACE nell'elenco daCL dell'oggetto specifica i diritti di accesso consentiti o negati per un trustee, che può essere un account utente, un account di gruppo o una sessione di accesso.

DACL

Il sistema confronta il truste in ogni ACE ai trustees identificati nel token di accesso del thread. Un token di accesso contiene identificatori di sicurezza (SID) che identificano l'utente e gli account di gruppo a cui appartiene l'utente. Un token contiene anche un SID di accesso che identifica la sessione di accesso corrente. Durante un controllo di accesso, il sistema ignora i SID di gruppo non abilitati. Per altre informazioni sui SID abilitati, disabilitati e negati, vedere Attributi SID in un token di accesso.

In genere, il sistema usa il token di accesso primario del thread che richiede l'accesso. Tuttavia, se il thread rappresenta un altro utente, il sistema usa il token di rappresentazione del thread.

Il sistema esamina ogni ACE in sequenza fino a quando non si verifica uno degli eventi seguenti:

• Un ACE negato all'accesso nega esplicitamente uno dei diritti di accesso richiesti a uno dei trustee elencati nel token di accesso del thread.
• Uno o più ACL consentiti per l'accesso per i trustees elencati nel token di accesso del thread concedono in modo esplicito tutti i diritti di accesso richiesti.
• Tutti gli ACL sono stati controllati ed è ancora presente almeno un diritto di accesso richiesto che non è stato consentito in modo esplicito, in cui l'accesso viene negato in modo implicito.

Nella figura seguente viene illustrato come l'elenco daCL di un oggetto può consentire l'accesso a un thread negando l'accesso a un altro.

Per Thread A, il sistema legge ACE 1 e nega immediatamente l'accesso perché l'ACE negato dall'accesso si applica all'utente nel token di accesso del thread. In questo caso, il sistema non controlla aces 2 e 3. Per Thread B, ACE 1 non si applica, quindi il sistema procede a ACE 2, che consente l'accesso in scrittura e ACE 3 che consente l'accesso in lettura ed esecuzione.

Poiché il sistema arresta il controllo degli ACL quando l'accesso richiesto viene concesso o negato in modo esplicito, l'ordine degli ACL in un daCL è importante. Si noti che se l'ordine ACE era diverso nell'esempio, il sistema potrebbe aver concesso l'accesso a Thread A. Per gli oggetti di sistema, il sistema operativo definisce un ordine preferito di AES in un'interfaccia di controllo livello dati.