Funcionamiento de AccessCheck
Cuando un subproceso intenta acceder a un objeto protegible, el sistema concede o deniega el acceso. Si el objeto no tiene una lista de control de acceso discrecional (DACL), el sistema concede acceso; de lo contrario, el sistema busca Access Control entradas (ACA) en la DACL del objeto que se aplica al subproceso. Cada ACE de la DACL del objeto especifica los derechos de acceso permitidos o denegados para un administrador, que pueden ser una cuenta de usuario, una cuenta de grupo o una sesión de inicio de sesión.
DACL
El sistema compara el administrador de confianza de cada ACE con los administradores identificados en el token de acceso del subproceso. Un token de acceso contiene identificadores de seguridad (SID) que identifican al usuario y a las cuentas de grupo a las que pertenece el usuario. Un token también contiene un SID de inicio de sesión que identifica la sesión de inicio de sesión actual. Durante una comprobación de acceso, el sistema omite los SID de grupo que no están habilitados. Para obtener más información sobre los SID habilitados, deshabilitados y de solo denegación, consulte Atributos de SID en un token de acceso.
Normalmente, el sistema usa el token de acceso principal del subproceso que solicita acceso. Sin embargo, si el subproceso suplanta a otro usuario, el sistema usa el token de suplantación del subproceso.
El sistema examina cada ACE en secuencia hasta que se produce uno de los siguientes eventos:
- Una ACE denegada de acceso deniega explícitamente cualquiera de los derechos de acceso solicitados a uno de los administradores enumerados en el token de acceso del subproceso.
- Uno o varios ACA permitidos para el acceso para los administradores enumerados en el token de acceso del subproceso conceden explícitamente todos los derechos de acceso solicitados.
- Se han comprobado todas las ACE y todavía hay al menos un derecho de acceso solicitado que no se ha permitido explícitamente, en cuyo caso, el acceso se deniega implícitamente.
En la ilustración siguiente se muestra cómo la DACL de un objeto puede permitir el acceso a un subproceso mientras se deniega el acceso a otro.
En el caso del subproceso A, el sistema lee ACE 1 e deniega inmediatamente el acceso porque la ACE denegada de acceso se aplica al usuario en el token de acceso del subproceso. En este caso, el sistema no comprueba las ACE 2 y 3. En el caso del subproceso B, ACE 1 no se aplica, por lo que el sistema continúa con ace 2, lo que permite el acceso de escritura y ACE 3, lo que permite el acceso de lectura y ejecución.
Dado que el sistema deja de comprobar los ACA cuando se concede o deniega explícitamente el acceso solicitado, es importante el orden de los ACE en una DACL. Tenga en cuenta que si el orden ACE era diferente en el ejemplo, es posible que el sistema haya concedido acceso a Thread A. En el caso de los objetos del sistema, el sistema operativo define un orden preferido de ACA en una DACL.