檢查IRP_MJ_CREATE的其他特殊案例

發行項
06/14/2023

如果呼叫端沒有 SeChangeNotifyPrivilege，其他特殊案例處理必須在檔案系統內IRP_MJ_CREATE處理期間發生。例如，可以使用其檔案識別碼或物件識別碼開啟的檔案，可能不允許呼叫端取得該檔案的路徑，因為呼叫端可能沒有周遊許可權可透過目錄樹狀結構取得物件。

您可能想要在檔案系統中考慮的案例：

FILE_OPEN_BY_FILE_ID — 呼叫端不應使用檔案名。由於此資訊 (周遊許可權) 只有在建立作業期間才知道，而且無法在檔案資訊查詢呼叫期間使用，因此在IRP_MJ_CREATE期間，檔案系統必須計算周遊許可權的相關資訊。
SL_OPEN_TARGET_DIRECTORY — 目標檔案可能不存在，而且必須檢查目錄是否有檔案建立存取權。如果目標存在，可能需要刪除存取權檢查。一般而言，刪除存取檢查會在IRP_MJ_SET_INFORMATION處理期間重新命名作業時完成。
FILE_SUPERSEDE 和 FILE_OVERWRITE — 破壞性作業需要額外的存取權限，即使呼叫端未明確要求這些許可權也一樣。例如，檔案系統可能需要 DELETE 存取，才能執行取代作業。
FILE_CREATE、 FILE_OPEN_IF和 FILE_OVERWRITE_IF — 有作用的作業需要存取建立新物件的父目錄。這是包含目錄的檢查，而不是物件本身，因此類似于先前的程式碼範例。
SL_FORCE_ACCESS_CHECK — 如果此值是在 I/O 堆疊位置中設定，則必須執行檢查，就像呼叫來自使用者模式，而不是核心模式一樣。因此，即使呼叫源自核心模式伺服器，安全性監視器常式的呼叫也應該指定 UserMode 。
檔案/目錄刪除 — 這可能以 (檔案的 ACL 狀態為基礎，例如，FILE_WRITE_DATA存取隱含允許刪除;如果您可以刪除資料，則具有檔案) 的有效刪除許可權，以及包含目錄的 ACL 狀態 (FILE_DELETE_CHILD許可權，例如) 。

下列程式碼範例示範FILE_SUPERSEDE和FILE_OVERWRITE的特殊案例處理，即使呼叫端未要求，仍會隱含要求其他存取。

{
ULONG NewAccess = Supersede ? DELETE : FILE_WRITE_DATA;
ACCESS_MASK AddedAccess = 0;
PACCESS_MASK DesiredAccess = 
    &IrpSp->Paramters.Create.SecurityContext->DesiredAccess;

//
// If the caller does not have restore privilege, they must have write
// access to the EA and attributes for overwrite or supersede.
//
if (0 == (AccessState->Flags & TOKEN_HAS_RESTORE_PRIVILEGE)) {
    *DesiredAccess |= FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES;

    //
    // Does the caller already have this access?
    //
    if (AccessState->PreviouslyGrantedAccess & NewAccess) {

        //
        // No - they need this as well
        //
        *DesiredAccess |= NewAccess;

    }

    //
    // Now check access using SeAccessCheck (omitted)
    //

}

此程式碼範例是檔案系統原則優先位置的良好範例。呼叫端未要求 DELETE 存取或FILE_WRITE_DATA存取，但這類存取是在根據檔案系統語意執行的作業中固有的。

共用方式為

檢查IRP_MJ_CREATE的其他特殊案例

意見反應

其他資源