3.已經檢查完了所有的ACE，但是仍然至少有一個請求訪問權限沒有被明確給予，這種情況下，訪問被拒絕。
從Windows Server 2003開始，DACL里ACE的順序為：
Explicit ACE:AccessDenied Explicit ACE:AccessAllowed Inherited ACE:Access Denied Inherited ACE:Access Allowed
這個遍歷規(guī)則和順序保證了明確拒絕優(yōu)先于明確允許；明確指定的訪問控制優(yōu)先于繼承的訪問控制。
以下的內容基于Win10PreX86(9926)。
在遍歷類型為ACCESS_ALLOWED_ACE_TYPE的ACE時，如果ACE的SID前綴為SePackagePrefixSid(S-1-15-2)或者SeCapabilityPrefixSid(S-1-15-3)，則跳轉到處理AppContainer訪問權限控制的邏輯：
圖12
如果ACE的SID前綴為SePackagePrefixSid(S-1-15-2)，會先看這個SID是否為ALLAPPLICATION PACKAGES，這是一個Well known SID
圖13
如果是這個SID，認為匹配成功，不需要再精確比較SID了；否則和Token的PackageSID做精確匹配：
圖14
如果ACE的SID前綴為SeCapabilityPrefixSid(S-1-15-3)，會嘗試匹配Token的Capabilities：
圖15
PackageSID或者Capabilities匹配成功后，會通過a13記錄獲取到的權限以及還剩下未獲取到的權限。a13是上層調用傳進來的結構指針，上一層函數會根據這個結構的值，判斷AppContainer進程是否獲取到了請求的訪問權限。
看看上一層函數SepAccessCheck的邏輯片段，var_AccessLowbox就是圖14/15里的a13。如果PackageSID或者CapabilitieSID給予的權限不能完全覆蓋用戶請求的權限（var_Remaining != 0），則訪問失�。�
