Freigeben über

Überprüfung auf andere Sonderfälle auf IRP_MJ_CREATE

  • Artikel

Andere Sonderfälle müssen während der IRP_MJ_CREATE Behandlung innerhalb des Dateisystems erfolgen, wenn der Aufrufer nicht über SeChangeNotifyPrivilege verfügt. Beispielsweise kann eine Datei, die mit ihrer Datei-ID oder Objekt-ID geöffnet werden kann, dem Aufrufer möglicherweise nicht erlauben, den Pfad zu dieser Datei abzurufen, da der Aufrufer möglicherweise nicht über die Durchlaufberechtigung verfügt, um über die Verzeichnisstruktur zum Objekt zu gelangen.

Die Fälle, die Sie in Ihrem Dateisystem berücksichtigen möchten:

  • FILE_OPEN_BY_FILE_ID — der Name der Datei sollte dem Aufrufer nicht zur Verfügung gestellt werden. Da diese Informationen (Traverse-Berechtigung) nur während des Erstellungsvorgangs bekannt sind und während eines Aufrufs der Dateiinformationsabfrage nicht verfügbar sind, müssen Informationen zur Traverse-Berechtigung während der IRP_MJ_CREATE vom Dateisystem berechnet werden.

  • SL_OPEN_TARGET_DIRECTORY : Die Zieldatei ist möglicherweise nicht vorhanden, und das Verzeichnis muss auf Dateierstellungszugriff überprüft werden. Wenn das Ziel vorhanden ist, ist möglicherweise eine Überprüfung des Löschzugriffs erforderlich. Normalerweise erfolgt die Überprüfung des Löschzugriffs zum Zeitpunkt des Umbenennungsvorgangs während IRP_MJ_SET_INFORMATION Verarbeitung.

  • FILE_SUPERSEDE und FILE_OVERWRITE – destruktive Vorgänge erfordern zusätzliche Zugriffsrechte, auch wenn der Aufrufer diese nicht explizit gefordert hat. Beispielsweise erfordert ein Dateisystem möglicherweise DELETE-Zugriff, um einen Ablösevorgang auszuführen.

  • FILE_CREATE, FILE_OPEN_IF und FILE_OVERWRITE_IF – konstruktive Vorgänge erfordern Zugriff auf das übergeordnete Verzeichnis, in dem das neue Objekt erstellt wird. Dies ist eine Überprüfung für das enthaltende Verzeichnis, nicht für das Objekt selbst, und ähnelt daher dem vorherigen Codebeispiel.

  • SL_FORCE_ACCESS_CHECK : Wenn dieser Wert im E/A-Stapelspeicherort festgelegt ist, muss die Überprüfung so durchgeführt werden, als ob der Aufruf aus dem Benutzermodus, nicht im Kernelmodus, erfolgt wäre. Daher sollten Aufrufe von Sicherheitsüberwachungsroutinen UserMode angeben, auch wenn der Aufruf von einem Kernelmodusserver stammt.

  • Datei-/Verzeichnislöschung : Dies kann auf dem ACL-Zustand der Datei basieren (z. B. FILE_WRITE_DATA Zugriff das Löschen implizit zulässt; wenn Sie die Daten löschen können, verfügen Sie über effektive Löschberechtigungen für die Datei) sowie auf dem ACL-Zustand des Verzeichnisses (z. B. FILE_DELETE_CHILD Berechtigung für das enthaltende Verzeichnis).

Das folgende Codebeispiel veranschaulicht die Behandlung von Sonderfällen für FILE_SUPERSEDE und FILE_OVERWRITE, beide Fälle, in denen der Aufrufer implizit zusätzlichen Zugriff erfordert, auch wenn er nicht angefordert wurde.

{
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)
    //

}

Dieses Codebeispiel ist ein gutes Beispiel dafür, dass die Dateisystemrichtlinie Vorrang hat. Der Aufrufer hat keinen DELETE-Zugriff oder FILE_WRITE_DATA Zugriff gefordert, aber dieser Zugriff ist inhärent dem Vorgang, der basierend auf der Semantik des Dateisystems ausgeführt wird.