Vérification des autres cas spéciaux sur IRP_MJ_CREATE

D’autres cas spéciaux de gestion doivent se produire pendant la IRP_MJ_CREATE au sein du système de fichiers si l’appelant n’a pas SeChangeNotifyPrivilege. Par exemple, un fichier qui peut être ouvert à l’aide de son ID de fichier ou de son ID d’objet peut ne pas permettre à l’appelant d’obtenir le chemin d’accès à ce fichier, car l’appelant peut ne pas avoir l’autorisation d’accéder à l’objet au moyen de l’arborescence du répertoire.

Les cas que vous souhaiterez peut-être prendre en compte dans votre système de fichiers :

• FILE_OPEN_BY_FILE_ID : le nom du fichier ne doit pas être mis à la disposition de l’appelant. Étant donné que ces informations (autorisation de traversée) sont connues uniquement pendant l’opération de création et ne sont pas disponibles lors d’un appel de requête d’informations sur les fichiers, les informations sur l’autorisation de traversée doivent être calculées par le système de fichiers pendant la IRP_MJ_CREATE.

• SL_OPEN_TARGET_DIRECTORY : le fichier cible n’existe peut-être pas et le répertoire doit être vérifié pour l’accès à la création de fichier. Si la cible existe, elle peut nécessiter une suppression d’accès case activée. Normalement, la suppression de l’accès case activée est effectuée au moment de l’opération de renommage pendant IRP_MJ_SET_INFORMATION traitement.

• FILE_SUPERSEDE et FILE_OVERWRITE : les opérations destructives nécessitent des droits d’accès supplémentaires, même si l’appelant ne les a pas explicitement demandés. Par exemple, un système de fichiers peut nécessiter un accès DELETE pour effectuer une opération de remplacement.

• FILE_CREATE, FILE_OPEN_IF et FILE_OVERWRITE_IF : les opérations constructives nécessitent l’accès au répertoire parent où le nouvel objet est créé. Il s’agit d’une case activée sur le répertoire conteneur, et non sur l’objet lui-même, et donc similaire à l’exemple de code précédent.

• SL_FORCE_ACCESS_CHECK : si cette valeur est définie à l’emplacement de la pile d’E/S, l’case activée doit être effectuée comme si l’appel provenait du mode utilisateur, et non du mode noyau. Par conséquent, les appels aux routines de surveillance de sécurité doivent spécifier UserMode même si l’appel provient d’un serveur en mode noyau.

• Suppression de fichiers/répertoires : elle peut être basée sur l’état de la liste de contrôle d’accès du fichier (par exemple, FILE_WRITE_DATA accès autorise implicitement la suppression ; si vous pouvez supprimer les données, vous disposez d’autorisations de suppression effectives sur le fichier) ainsi que de l’état de la liste de contrôle d’accès du répertoire (FILE_DELETE_CHILD autorisation sur le répertoire conteneur, par exemple).

L’exemple de code suivant illustre la gestion de cas spéciale pour FILE_SUPERSEDE et FILE_OVERWRITE, deux cas où un accès supplémentaire est implicitement requis par l’appelant, même s’il n’a pas été demandé.

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

}

Cet exemple de code est un bon exemple de stratégie de système de fichiers prioritaire. L’appelant n’a pas demandé l’accès DELETE ou l’accès FILE_WRITE_DATA, mais cet accès est inhérent à l’opération effectuée en fonction de la sémantique du système de fichiers.