Проверка на наличие других особых случаев в IRP_MJ_CREATE

Во время обработки IRP_MJ_CREATE в файловой системе должна выполняться другая обработка особых случаев, если вызывающий объект не имеет SeChangeNotifyPrivilege. Например, файл, который можно открыть с помощью идентификатора файла или идентификатора объекта, может не позволить вызывающей объекту получить путь к этому файлу, так как вызывающий объект может не иметь разрешения на переход к объекту с помощью структуры дерева каталогов.

Варианты, которые вы можете рассмотреть в файловой системе:

• 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 — если это значение задано в расположении стека ввода-вывода, проверка должно выполняться так, как если бы вызов выполнялся в пользовательском режиме, а не в режиме ядра. Таким образом, вызовы подпрограмм монитора безопасности должны указывать 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 доступ, но такой доступ присущ операции, выполняемой на основе семантики файловой системы.