Contrôle de compte d’utilisateur pour les développeurs de jeux

Cet article décrit les recommandations et les meilleures pratiques permettant aux développeurs de jeux de travailler efficacement avec la fonctionnalité de sécurité du contrôle de compte d’utilisateur (UAC) introduite dans Windows Vista.

• Vue d’ensemble du contrôle de compte d’utilisateur
• Comptes d’utilisateur dans Windows Vista
• Accès aux fichiers en tant qu’utilisateur standard
• Accès au Registre en tant qu’utilisateur standard
• Privilege Elevation (élévation des privilèges)
• Implications de la UAC avec CreateProcess()
• Définition du niveau d’exécution dans le manifeste de l’application
• Incorporation d’un manifeste dans Visual Studio
• Compatibilité UAC avec les jeux plus anciens
• Scénarios et manifestes hérités
• Conclusion
• En savoir plus

Vue d’ensemble du contrôle de compte d’utilisateur

Le contrôle de compte d’utilisateur (UAC), introduit dans Windows Vista, est une fonctionnalité de sécurité conçue pour empêcher les attaquants malveillants d’utiliser des faiblesses ou des bogues trouvés dans des applications largement utilisées pour modifier le système d’exploitation ou d’autres programmes installés. Pour ce faire, exécutez la grande majorité des programmes et des processus en tant qu’utilisateur standard (également appelé utilisateur limité, utilisateur restreint ou utilisateur Least-Privileged) même si le compte de l’utilisateur actuel possède des informations d’identification administratives. Un processus avec des privilèges utilisateur standard a de nombreuses restrictions inhérentes qui l’empêchent d’apporter des modifications à l’échelle du système.

UAC est également responsable de l’élévation des privilèges d’un processus à l’aide d’un schéma d’authentification basé sur un dialogue lancé lors de l’exécution de certains processus désignés comme nécessitant des privilèges d’administration. L’élévation de privilèges permet aux administrateurs d’exécuter la majorité de leurs applications à un niveau de privilège sécurisé (identique à tout autre utilisateur standard), mais également d’autoriser les processus et les opérations qui nécessitent des privilèges administratifs. UAC prend en charge l’authentification par-dessus épaule afin qu’un administrateur puisse accorder des privilèges élevés à un programme pendant qu’un utilisateur standard est actuellement connecté au système.

La fonctionnalité UAC est activée par défaut. Bien qu’il soit possible pour un administrateur de désactiver l’UAC à l’échelle du système, cela a un certain nombre de conséquences négatives. Tout d’abord, cela affaiblit la sécurité de tous les comptes d’administration, car tous les processus sont exécutés avec des informations d’identification administratives, même si la plupart des applications n’en ont pas réellement besoin. Lorsque l’UAC est désactivé, une application utilisateur standard qui expose une vulnérabilité exploitable en matière de sécurité peut potentiellement être utilisée pour voler des informations privées, installer des rootkits ou des logiciels espions, détruire l’intégrité du système ou héberger des attaques zombies sur d’autres systèmes. Si l’UAC est activé, l’exécution de la majorité des logiciels en tant qu’utilisateur standard limite considérablement les dommages potentiels d’un tel bogue. Deuxièmement, la désactivation du contrôle d’utilisateur désactive la plupart des solutions de contournement pour la compatibilité des applications qui permettent à de véritables utilisateurs standard d’exécuter correctement un large éventail d’applications. La désactivation du contrôle d’utilisateur ne doit jamais être recommandée comme solution de contournement de compatibilité.

Il est important de noter que les applications doivent s’efforcer d’utiliser uniquement les droits d’utilisateur standard si possible. Bien que les administrateurs puissent facilement élever les privilèges d’un processus, l’élévation nécessite toujours une interaction et un accusé de réception de l’utilisateur chaque fois qu’une application nécessitant des informations d’identification administratives est exécutée. Cette élévation doit également être effectuée au moment du démarrage du programme, de sorte que l’exigence d’informations d’identification administratives, même pour une seule opération, nécessite d’exposer le système à un risque plus élevé pendant toute la durée d’exécution de l’application. Les utilisateurs standard sans possibilité d’élever leurs privilèges sont également courants dans les paramètres familiaux et professionnels. « Exécuter en tant qu’administrateur » n’est pas une bonne solution de contournement pour la compatibilité, expose l’utilisateur et le système à des risques de sécurité plus importants et crée de la frustration pour les utilisateurs dans de nombreuses situations.

Comptes d’utilisateur dans Windows Vista

Windows Vista classe chaque utilisateur en deux types de comptes d’utilisateur : les administrateurs et les utilisateurs standard.

Un compte d’utilisateur standard est similaire à un compte d’utilisateur limité dans Windows XP. Comme dans Windows XP, un utilisateur standard ne peut pas écrire dans le dossier Program Files, ne peut pas écrire dans la partie HKEY_LOCAL_MACHINE du Registre et ne peut pas effectuer des tâches qui modifient le système, telles que l’installation d’un pilote en mode noyau ou l’accès aux espaces de processus au niveau du système.

Le compte Administrateur a considérablement changé depuis la publication de Windows XP. Auparavant, tous les processus lancés par un membre du groupe Administrateurs recevaient des privilèges d’administration. Une fois le contrôle D’utilisateur activé, tous les processus s’exécutent avec des privilèges utilisateur standard, sauf s’ils sont spécifiquement élevés par un administrateur. Cette différence rend les comptes du groupe Administrateurs plus sécurisés en réduisant le risque de sécurité posé par les bogues potentiels dans la plupart des programmes.

Il est important que toutes les applications, en particulier les jeux, fonctionnent efficacement et de manière responsable lorsqu’elles sont exécutées en tant que processus utilisateur standard. Toutes les opérations qui nécessitent des privilèges administratifs doivent être effectuées au moment de l’installation ou par des programmes auxiliaires qui demandent explicitement des informations d’identification administratives. Bien que l’élévation des privilèges soit assez triviale pour un membre du groupe Administrateurs, les utilisateurs standard doivent s’en remettre à une personne disposant d’informations d’identification administratives pour entrer physiquement leur mot de passe afin d’élever les privilèges. Étant donné que les comptes protégés par le contrôle parental doivent être des utilisateurs standard, il s’agit d’une situation très courante pour les joueurs qui utilisent Windows Vista.

Si votre jeu fonctionne déjà sur Windows XP avec des comptes d’utilisateur limités, le passage à Contrôle de compte d’utilisateur sur Windows Vista doit être très facile. La majorité de ces applications fonctionnent telles quelles, bien que l’ajout d’un manifeste d’application soit fortement recommandé. (Les manifestes sont décrits plus loin dans cette rubrique dans Définition du niveau d’exécution dans le manifeste de l’application.)

Accès aux fichiers en tant qu’utilisateur standard

L’aspect de votre jeu le plus affecté par les restrictions utilisateur standard est l’organization et l’accessibilité du système de fichiers. Vous ne devez jamais supposer que votre jeu peut écrire des fichiers dans le dossier où votre jeu est installé. Dans Windows Vista pour instance, les privilèges d’un utilisateur doivent être élevés par le système d’exploitation pour qu’une application puisse écrire dans le dossier Program Files. Pour éviter cela, vous devez classer vos fichiers de données de jeu par étendue et accessibilité, et utiliser la fonction SHGetFolderPath , ainsi que les constantes CSIDL fournies par l’interpréteur de commandes Windows, pour générer les chemins de fichiers appropriés. Les constantes CSIDL correspondent aux dossiers connus dans le système de fichiers que le système d’exploitation utilise et promeut pour partitionner des fichiers globaux et spécifiques à l’utilisateur.

Toute tentative de création ou d’écriture d’un fichier ou d’un répertoire dans un dossier qui n’accorde pas d’autorisation d’écriture au processus échoue sous Windows Vista si l’application ne dispose pas de privilèges d’administration. Si votre exécutable de jeu 32 bits s’exécute en mode hérité, car il n’a pas déclaré de niveau d’exécution demandé, ses opérations d’écriture réussissent, mais elles sont soumises à la virtualisation, comme décrit dans la section « Compatibilité des UAC avec les jeux plus anciens » plus loin dans cet article.

Tableau 1. Dossiers connus

Votre jeu est généralement installé dans un dossier sous le dossier représenté par la constante CSIDL_PROGRAM_FILES. Toutefois, ce n'est pas toujours le cas. Vous devez plutôt utiliser un chemin d’accès relatif à partir de votre fichier exécutable lors de la génération de chaînes de chemin d’accès aux fichiers ou répertoires situés sous votre dossier d’installation.

Vous devez également vous abstenir d’hypothèses codées en dur concernant les chemins d’accès aux dossiers connus. Par exemple, sur Windows XP Professionnel Édition 64 bits et Windows Vista x64, le chemin des fichiers programme est C:\Program Files (x86) pour les programmes 32 bits et C:\Program Files pour les programmes 64 bits. Ces chemins connus sont modifiés à partir de Windows XP, et les utilisateurs peuvent reconfigurer l’emplacement de la plupart de ces dossiers et même les localiser sur différents lecteurs. Par conséquent, utilisez toujours les constantes CSIDL pour éviter toute confusion et tout problème potentiel. Le programme d’installation de Windows comprend ces emplacements de dossiers connus et déplace les données lors de la mise à niveau du système d’exploitation à partir de Windows XP ; en revanche, l’utilisation d’emplacements non standard ou de chemins codés en dur peut échouer après une mise à niveau du système d’exploitation.

Il convient de prêter attention aux différences subtiles d’utilisation entre les dossiers spécifiques à l’utilisateur spécifiés par CSIDL_PERSONAL et CSIDL_LOCAL_APPDATA. La pratique recommandée pour sélectionner la constante CSIDL à utiliser pour écrire un fichier consiste à utiliser CSIDL_PERSONAL si l’utilisateur est censé interagir avec le fichier, par exemple double-cliquer dessus pour l’ouvrir dans un outil ou une application, et utiliser CSIDL_LOCAL_APPDATA pour d’autres fichiers. Les deux dossiers peuvent être exploités par votre application pour stocker et organiser des fichiers de données spécifiques à l’utilisateur, car il n’existe aucune différence dans leur étendue d’accès ou leur niveau de privilège. Veillez à créer des noms de chemins suffisamment uniques pour ne pas entrer en collision avec d’autres applications, mais suffisamment courts pour que le nombre de caractères dans le chemin complet soit inférieur à la valeur de MAX_PATH, 260.

Le code suivant fournit un exemple d’écriture d’un fichier dans un dossier connu :

#include <windows.h>
#include <shlobj.h>
#include <shlwapi.h>
        ...
        ...
        ...
        TCHAR strPath[MAX_PATH];
        if( SUCCEEDED(
        SHGetFolderPath( NULL, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, strPath ) ) )
        {
        PathAppend( strPath, TEXT( "Company Name\\Title" ) );

        if( !PathFileExists( strPath ) )
        {
        if( ERROR_SUCCESS != SHCreateDirectoryEx( NULL, strPath, NULL ) )
        return E_FAIL;
        }

        PathAppend( strPath, TEXT( "gamefile.txt" ) );

        // strPath is now something like:
        // C:\Users\<current user>\Documents\Company Name\Title\gamefile.txt
        // Open the file for writing
        HANDLE hFile = CreateFile(strPath, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

        if( INVALID_HANDLE_VALUE != hFile )
        {
        // TODO: Write to file
        CloseHandle(hFile);
        }
        }

Accès au Registre en tant qu’utilisateur standard

L’accès au Registre par un utilisateur standard est limité de la même façon que le système de fichiers. Un utilisateur standard est autorisé à accéder en lecture à toutes les clés du Registre ; Toutefois, l’accès en écriture est accordé uniquement à la sous-arborescence HKEY_CURRENT_USER (HKCU), qui est mappée en interne à la sous-clé spécifique à l’utilisateur HKEY_USERS\Security ID (SID) de l’utilisateur actuel. Une application qui doit écrire dans n’importe quel emplacement de Registre autre que HKEY_CURRENT_USER nécessite des privilèges d’administration.

Si l’application 32 bits ne contient pas de niveau d’exécution demandé dans son manifeste, toutes les écritures dans HKEY_LOCAL_MACHINE\Software sont virtualisées, tandis que les écritures dans d’autres emplacements en dehors de HKEY_CURRENT_USER échouent.

Il n’est pas recommandé de stocker des données persistantes dans le Registre, comme la configuration d’un utilisateur. La méthode recommandée pour stocker des données persistantes à partir de votre jeu consiste à écrire les données dans le système de fichiers en appelant SHGetFolderPath et à obtenir la valeur d’une constante CSIDL, décrite dans la section précédente.

Privilege Elevation (élévation des privilèges)

Dans Windows Vista, toute application qui nécessite des privilèges d’administration doit déclarer une demande pour un niveau d’exécution administratif dans son manifeste (décrit dans la section suivante, Définition du niveau d’exécution dans le manifeste de l’application).

L’élévation, comme on l’appelle, est la procédure pilotée par le contrôle d’utilisateur pour promouvoir un processus en processus administratif. Les privilèges d’un processus ne peuvent être élevés qu’au moment de la création. Une fois créé, un processus ne sera jamais promu à un niveau de privilège supérieur. Pour cette raison. les opérations qui nécessitent des informations d’identification administratives doivent être isolées dans des programmes d’installation distincts et d’autres programmes auxiliaires.

Lors de l’exécution d’un programme, UAC inspecte le niveau d’exécution demandé dans le manifeste et, si des privilèges élevés sont requis, invite l’utilisateur actuel avec l’une des deux boîtes de dialogue standard : une pour un utilisateur standard et une pour un administrateur.

Si l’utilisateur actuel est un utilisateur standard, UAC invite l’utilisateur à entrer les informations d’identification d’un administrateur avant d’autoriser l’exécution du programme.

Figure 1. Demander à un utilisateur Standard d’entrer les informations d’identification d’un compte d’administration

Si l’utilisateur actuel est un administrateur, le contrôle D’utilisateur invite l’utilisateur à fournir l’autorisation avant d’autoriser l’exécution du programme.

Figure 2 : Demander à un administrateur d’autoriser les modifications apportées à l’ordinateur

L’application se verra accorder des privilèges administratifs uniquement si un utilisateur standard fournit les informations d’identification administratives appropriées ou si un utilisateur administratif fournit un accusé de réception ; Tout autre élément entraîne l’arrêt de l’application.

Il est important de noter qu’un processus avec des privilèges élevés s’exécute en tant qu’utilisateur administratif qui a entré des informations d’identification dans l’invite UAC plutôt qu’en tant qu’utilisateur standard actuellement connecté. Cela est similaire à l’exécution dans Windows XP, le processus avec élévation de privilèges obtient le dossier et les clés de Registre de l’administrateur lors de l’accès aux données par utilisateur, et tous les programmes lancés par le processus avec élévation de privilèges héritent également des droits d’administration et des emplacements des comptes d’utilisateur. Pour les administrateurs qui sont invités à fournir un accusé de réception (Continuer ou Annuler), ces emplacements correspondent aux emplacements de l’utilisateur actuel. En général, toutefois, les processus qui nécessitent une élévation ne doivent pas fonctionner sur les données par utilisateur. Notez que cela peut affecter considérablement le fonctionnement de votre programme d’installation . Si le programme d’installation, exécuté en tant qu’administrateur, écrit dans HKCU ou dans le profil d’un utilisateur, il peut très bien écrire à un emplacement incorrect. Envisagez de créer ces valeurs par utilisateur lors de la première exécution du jeu.

Implications de la UAC avec CreateProcess()

Le mécanisme d’élévation de contrôle d’utilisateur ne sera pas appelé à partir d’un appel à la fonction Win32 CreateProcess() pour démarrer un exécutable configuré pour exiger un niveau d’exécution supérieur au processus actuel. Par conséquent, l’appel à CreateProcess() échoue avec GetLastError() qui retourne ERROR_ELEVATION_REQUIRED. CreateProcess() réussit uniquement lorsque le niveau d’exécution de l’appelé est égal ou inférieur à celui de l’appelant. Un processus non élevé qui doit générer des processus élevés doit le faire à l’aide de la fonction ShellExecute(), ce qui entraîne le déclenchement du mécanisme d’élévation de contrôle d’utilisateur au moyen de l’interpréteur de commandes.

Définition du niveau d’exécution dans le manifeste de l’application

Vous déclarez le niveau d’exécution demandé de votre jeu en ajoutant une extension au manifeste de l’application. Le code XML suivant montre la configuration minimale requise pour définir le niveau d’exécution d’une application :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
        <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
                <ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
        </ms_asmv2:security>
    </ms_asmv2:trustInfo>
</assembly>

Dans le code précédent, le système d’exploitation est informé que le jeu nécessite uniquement des privilèges utilisateur standard par la balise suivante :

<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />

En définissant explicitement requestedExecutionLevel sur « asInvoker », cet exemple indique au système d’exploitation que le jeu se comportera correctement sans privilèges d’administrateur. Par conséquent, la UAC désactive la virtualisation et exécute le jeu avec les mêmes privilèges que l’appelant, qui est généralement des privilèges utilisateur standard, car Windows Explorer s’exécute en tant qu’utilisateur standard.

Le système d’exploitation peut être informé qu’un jeu nécessite une élévation de privilèges administratifs en remplaçant « asInvoker » par « requireAdministrator », pour créer la balise suivante :

<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Avec cette configuration, le système d’exploitation invite l’utilisateur actuel à utiliser l’une des boîtes de dialogue d’élévation de contrôle d’utilisateur standard chaque fois que le jeu est exécuté. Il est fortement recommandé qu’aucun jeu ne nécessite de privilèges d’administrateur pour s’exécuter, car non seulement ce dialogue deviendra rapidement ennuyeux, mais il rend également le jeu incompatible avec les contrôles parentaux. Réfléchissez très attentivement avant d’ajouter cette exigence à un exécutable.

Une erreur courante est que l’ajout d’un manifeste qui définit requestedExecutionLevel sur « requireAdministrator » contourne la nécessité d’une invite d’élévation. Ce n’est pas vrai. Cela empêche simplement le système d’exploitation de deviner si votre application d’installation ou de mise à jour a besoin de privilèges d’administration. L’utilisateur est toujours invité à autoriser l’élévation.

Windows vérifie la signature de toute application marquée pour l’élévation avant d’afficher l’invite UAC. Un fichier exécutable volumineux marqué pour l’élévation prend plus de temps à case activée qu’un petit exécutable et plus long qu’un exécutable marqué comme « asInvoker ». Les exécutables d’installation qui s’extraient automatiquement doivent donc être marqués comme « asInvoker », et toute partie qui doit être marquée comme « requireAdministrator » doit être placée dans un exécutable d’assistance distinct.

L’attribut uiAccess, illustré dans les exemples précédents, doit toujours avoir la valeur FALSE pour les jeux. Cet attribut spécifie si les clients UI Automation ont accès à l’interface utilisateur du système protégé et qu’il a des implications de sécurité particulières s’il est défini sur TRUE.

Incorporation d’un manifeste dans Visual Studio

La prise en charge des manifestes a été ajoutée à Visual Studio à partir de VS2005. Par défaut, un fichier exécutable créé dans Visual Studio 2005 (ou version ultérieure) aura un manifeste généré automatiquement dans celui-ci dans le cadre du processus de génération. Le contenu du manifeste généré automatiquement dépend de certaines configurations de projet que vous spécifiez dans la boîte de dialogue propriétés du projet.

Le manifeste généré automatiquement par Visual Studio 2005 ne contiendra pas de <bloc trustInfo> , car il n’existe aucun moyen de configurer le niveau d’exécution du contrôle d’utilisateur dans les propriétés du projet. La meilleure façon d’ajouter ces informations consiste à permettre à VS2005 de fusionner un manifeste défini par l’utilisateur contenant le <bloc trustInfo> avec le manifeste généré automatiquement. Il s’agit simplement d’ajouter un fichier *.manifest à votre solution qui contient le code XML répertorié dans la section précédente. Lorsque Visual Studio rencontre un fichier .manifest dans votre solution, il appelle automatiquement l’outil Manifeste (mt.exe) pour fusionner les fichiers .manifest avec celui généré automatiquement.

Un inconvénient dans l’utilisation de l’outil mt.exe inclus dans Visual Studio 2005 est qu’il génère un avertissement lors du traitement du <bloc trustInfo> , car l’outil ne contient pas de schéma mis à jour pour valider le code XML. Pour remédier à cet avertissement, il est recommandé de remplacer tous les fichiers mt.exe dans le répertoire d’installation de Visual Studio 2005 (il existe plusieurs instances) par les mt.exe fournies dans le dernier kit sdk Windows.

À compter de Visual Studio 2008, vous pouvez désormais spécifier le niveau d’exécution d’une application à partir de la boîte de dialogue propriétés du projet (Figure 3) ou à l’aide de l’indicateur de l’éditeur de liens /MANIFESTUAC. Si vous définissez ces options, Visual Studio 2008 génère automatiquement et incorpore un manifeste avec le bloc trustInfo> approprié <dans l’exécutable.

Figure 3. Définition du niveau d’exécution dans Visual Studio 2008

L’incorporation d’un manifeste dans des versions antérieures de Visual Studio sans prise en charge du manifeste est toujours possible, mais nécessite davantage de travail de la part du développeur. Pour obtenir un exemple sur la façon de procéder, examinez le projet Visual Studio 2003 inclus dans n’importe quel exemple du Kit de développement logiciel (SDK) DirectX antérieur à la version de mars 2008.

Compatibilité UAC avec les jeux plus anciens

Si votre jeu semble enregistrer et charger correctement un fichier dans le répertoire Program Files, mais qu’aucune preuve du fichier iOn Windows Vista, toute application 32 bits qui ne contient pas de niveau d’exécution demandé dans son manifeste est considérée comme une application héritée. Avant Windows Vista, la plupart des applications étaient généralement exécutées par des utilisateurs disposant de privilèges d’administration. Par conséquent, ces applications pouvaient lire et écrire librement des fichiers système et des clés de Registre, et de nombreux développeurs n’ont pas apporté les modifications nécessaires pour fonctionner correctement sur les comptes d’utilisateur limités sur Windows XP. Toutefois, sur Windows Vista, ces mêmes applications échouent désormais en raison de privilèges d’accès insuffisants dans le nouveau modèle de sécurité, qui applique l’exécution utilisateur standard pour les applications héritées. Pour atténuer l’impact de cela, la virtualisation a également été ajoutée à Windows Vista. La virtualisation permettra à des milliers d’applications héritées de fonctionner correctement sur Windows Vista sans exiger que ces applications disposent de privilèges élevés à tout moment simplement pour réussir quelques opérations mineures. s trouvé, il y a de fortes chances que votre jeu s’exécute en mode hérité et ait été soumis à la virtualisation.

La virtualisation affecte le système de fichiers et le Registre en redirigeant les écritures sensibles au système (et les opérations de fichier ou de Registre suivantes) vers un emplacement par utilisateur dans le profil de l’utilisateur actuel. Par exemple, si une application tente d’écrire dans le fichier suivant :

C:\\Program Files\\Company Name\\Title\\config.ini

l’écriture est automatiquement redirigée vers :

C:\\Users\\user name\\AppData\\Local\\VirtualStore\\Program Files\\Company Name\\Title\\config.ini

De même, si une application tente d’écrire une valeur de Registre comme suit :

HKEY\_LOCAL\_MACHINE\\Software\\Nom de l’entreprise\\Title

il sera redirigé à la place vers :

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Nom de l’entreprise\\Title

Les fichiers et les clés de Registre affectés par la virtualisation sont uniquement accessibles par les opérations de fichier et de Registre à partir d’applications virtualisées qui s’exécutent en tant qu’utilisateur actuel.

Toutefois, il existe de nombreuses restrictions à la virtualisation. La première est que les applications 64 bits ne sont jamais exécutées en mode hérité, car les opérations de compatibilité soumises à la virtualisation dans les applications 32 bits échouent simplement en 64 bits. En outre, si une application héritée s’exécutant en tant qu’utilisateur standard tente d’écrire un type de fichier exécutable dans un emplacement qui nécessite des informations d’identification administratives, la virtualisation ne se produit pas et l’écriture échoue.

Figure 4. Processus de virtualisation

Lorsqu’une application héritée tente une opération de lecture sur des emplacements sensibles au système de fichiers ou dans le Registre, les emplacements virtuels sont recherchés en premier. Si le fichier ou la clé de Registre est introuvable, le système d’exploitation accède aux emplacements système par défaut.

La virtualisation étant supprimée des versions ultérieures de Windows, il est important de ne pas s’appuyer sur cette fonctionnalité. Au lieu de cela, vous devez configurer explicitement votre manifeste d’application pour les privilèges d’utilisateur standard ou d’administrateur, car cela désactivera la virtualisation. La virtualisation n’étant pas évidente pour les utilisateurs finaux, même si la virtualisation peut permettre à votre application de s’exécuter, elle peut générer des appels de support et compliquer la résolution des problèmes pour ces clients.

Notez que si l’UAC est désactivée, la virtualisation est également désactivée. Si la virtualisation est désactivée, les comptes d’utilisateur standard se comportent exactement comme des comptes d’utilisateur limités dans Windows XP, et les applications héritées peuvent ne pas fonctionner correctement pour les utilisateurs standard qui auraient autrement réussi en raison de la virtualisation.

Scénarios et manifestes hérités

Dans la majorité des scénarios d’utilisation, il suffit de marquer le .exe avec les éléments de manifeste UAC corrects et de s’assurer que l’application fonctionne correctement en tant qu’utilisateur standard pour une excellente compatibilité UAC. La plupart des joueurs exécutent Windows Vista ou Windows 7 avec le contrôle de compte d’utilisateur activé. Pour Windows XP et les utilisateurs sur Windows Vista ou Windows7 avec la fonctionnalité Contrôle de compte d’utilisateur désactivée, ils s’exécutent généralement à l’aide de comptes d’administrateur. Bien qu’il s’agisse d’un mode de fonctionnement moins sécurisé, il ne rencontrera généralement pas de problèmes de compatibilité supplémentaires, bien que, comme indiqué ci-dessus, la désactivation de L’UAC désactive également la virtualisation.

Il existe un cas particulier à noter lorsque le programme est marqué comme « requireAdministrator » dans le manifeste UAC. Sur Windows XP et sur Windows Vista ou Windows 7 avec le contrôle de compte d’utilisateur désactivé, les éléments du manifeste UAC sont ignorés par le système. Dans ce cas, les utilisateurs disposant de comptes d’administrateur exécutent toujours tous les programmes avec des droits d’administrateur complets. Ces programmes fonctionnent donc comme prévu. Toutefois, les utilisateurs windows XP restreints et les utilisateurs standard s’exécutant sur Windows Vista ou Windows 7 exécutent toujours ces programmes avec des droits restreints et toutes les opérations au niveau de l’administrateur échouent. Il est donc recommandé que les programmes marqués comme « requiretAdministrator » appellent IsUserAnAdmin au démarrage et affichent un message d’erreur irrécupérable s’il retourne FALSE. Pour le scénario majoritaire ci-dessus, cela réussit toujours, mais fournit une meilleure expérience utilisateur et un message d’erreur clair pour cette situation rare.

Conclusion

En tant que développeur de jeux ciblant l’environnement multi-utilisateur Windows, il est impératif que vous conceviez votre jeu pour fonctionner efficacement et de manière responsable. Le fichier exécutable main de votre jeu ne doit pas dépendre des privilèges administratifs. Cela empêche non seulement l’apparition d’invites d’élévation chaque fois que votre jeu est exécuté, ce qui peut avoir un impact négatif sur l’expérience utilisateur globale, mais cela permet également à votre jeu de tirer parti d’autres fonctionnalités qui nécessitent une exécution avec des privilèges utilisateur standard, tels que le contrôle parental.

Les applications qui sont correctement conçues pour fonctionner comme avec les informations d’identification d’un utilisateur standard (ou d’un utilisateur limité) sous les versions précédentes de Windows ne seront pas affectées par la UAC qu’elles s’exécuteront sans élévation. Toutefois, ils doivent inclure un manifeste avec le niveau d’exécution demandé défini sur « asInvoker » pour se conformer aux normes d’application pour Vista.

En savoir plus

Pour obtenir de l’aide sur la conception d’applications pour Windows Vista conformes au contrôle de compte d’utilisateur, téléchargez le livre blanc suivant : Exigences de développement d’applications Windows Vista pour la compatibilité du contrôle de compte d’utilisateur.

Ce livre blanc fournit des étapes détaillées sur le processus de conception, ainsi que des exemples de code, des exigences et des meilleures pratiques. Ce document détaille également les mises à jour techniques et les modifications apportées à l’expérience utilisateur dans Windows Vista.

Pour plus d’informations sur le contrôle de compte d’utilisateur, consultez Windows Vista : Contrôle de compte d’utilisateur sur Microsoft TechNet.

Une autre ressource utile est l’article Apprendre à vos applications à jouer correctement avec le contrôle de compte d’utilisateur Windows Vista, de MSDN Magazine, janvier 2007. Cet article traite des problèmes généraux de compatibilité des applications, ainsi que des avantages et des problèmes liés à l’utilisation de packages Windows Installer sur Windows Vista.

Pour plus d’informations sur le bogue et le correctif pour mt.exe, l’outil utilisé par Visual Studio 2005 pour fusionner et incorporer automatiquement un manifeste dans un fichier exécutable, consultez Exploration des manifestes Partie 2 : Espaces de noms par défaut et manifestes UAC dans Windows Vista sur le blog de Chris Jackson sur MSDN.