Jeux avec des comptes d’utilisateur Least-Privileged

Cet article décrit comment les développeurs de jeux peuvent créer des jeux Microsoft Windows qui fonctionnent bien avec des comptes d’utilisateur avec des comptes d’utilisateur avec des privilèges minimum (également appelés comptes d’utilisateurs limités).

Introduction

Windows gère ses utilisateurs avec des comptes. Aujourd’hui, plus de 80 % des utilisateurs de l’ordinateur à la maison partagent leur ordinateur avec d’autres membres de la famille. Lorsque plusieurs utilisateurs partagent un ordinateur Windows, plusieurs comptes d’utilisateur sont créés et chaque utilisateur se connecte avec un compte individuel pour accéder à l’ordinateur. Avec la sensibilisation croissante à la sécurité, davantage de personnes exploitent leurs ordinateurs avec des comptes d’utilisateur avec des comptes d’utilisateur avec des privilèges minimum, également appelés comptes d’utilisateur limités, qui n’ont pas de contrôle total sur le système. Les comptes d’administrateur disposent généralement d’un accès illimité à chaque partie de l’ordinateur. Cela peut affecter le fonctionnement des jeux basés sur Windows.

Il existe des avantages supplémentaires pour les développeurs de jeux qui écrivent leurs jeux pour travailler avec des comptes d’utilisateur avec des comptes d’utilisateur avec des privilèges minimum. Dans Windows Vista et versions ultérieures, les comptes d’utilisateur avec des privilèges minimum sont appliqués, ce qui signifie que chaque compte sur le système, à l’exception de l’administrateur local, est un compte d’utilisateur avec des privilèges minimum. Cela affectera la façon dont les jeux qui ne suivent pas les instructions (applications héritées) s’exécutent sur Windows Vista et versions ultérieures. Par exemple, lorsqu’une application tente d’écrire dans un dossier ou une valeur de Registre dans laquelle elle n’est pas autorisée, l’écriture du fichier est redirigée vers un magasin de fichiers virtuel pour l’utilisateur. Ce magasin de fichiers virtuels réside dans un dossier auquel l’utilisateur dispose d’un accès en écriture. Ce comportement peut ne pas sembler aussi catastrophique que l’échec total de la tentative d’écriture; Toutefois, les applications qui créent des fichiers virtualisés peuvent confondre les utilisateurs, car les fichiers ne seront pas écrits dans l’emplacement attendu par les utilisateurs. Par exemple, les jeux qui écrivent des fichiers de score élevé dans le même dossier que le dossier exécutable écrivent ces fichiers dans un dossier virtualisé à la place. Par conséquent, un utilisateur ne peut pas voir le score élevé obtenu par un autre utilisateur, car chaque utilisateur dispose d’un magasin de fichiers virtualisé distinct.

Les jeux qui suivent les instructions de cet article s’exécutent avec des comptes d’utilisateur avec des comptes d’utilisateur avec des privilèges minimum et, par conséquent, maintiendront la compatibilité avec Windows Vista et versions ultérieures.

Accès aux fichiers pour les comptes d’utilisateur Least-Privileged

Windows prend en charge deux systèmes de fichiers : FAT32 et NTFS. FAT32 est un système de fichiers hérité pris en charge uniquement pour la compatibilité descendante ; NTFS prend en charge des autorisations de fichiers plus puissantes et robustes. L’utilisation de NTFS s’étend à mesure que les détaillants expédient de nouveaux ordinateurs avec Windows préinstallé sur un disque dur partitionné NTFS. Sur un système WINDOWS XP basé sur NTFS, les utilisateurs disposant de comptes d’utilisateur avec des privilèges minimum n’ont qu’un accès limité à plusieurs dossiers. Toutefois, ils auraient un accès complet sur un système FAT32 Windows XP.

Le tableau suivant répertorie l’emplacement par défaut de ces dossiers et leurs autorisations.

Chemin d’accès Contenu du dossier Lire Write Créer/Supprimer
<Lecteur> :\Windows Système d’exploitation Windows X
<Drive>:\Program Files Fichiers d’application exécutables X
<Drive>:\Documents and Paramètres\Username* Fichiers de chaque utilisateur X X X
<Lecteur> :\Documents et Paramètres\Tous les utilisateurs Tous les fichiers utilisateur X X X

 

* Nom d’utilisateur est le nom de connexion de l’utilisateur.

Dans un compte d’utilisateur avec des privilèges minimum, vous pouvez lire, écrire, créer et supprimer des fichiers dans les deux dossiers : Documents et Paramètres\Nom d’utilisateur ou Documents et Paramètres\Tous les utilisateurs.

Cela signifie que vous ne devez pas placer les jeux d’enregistrement dans \Program Files, au lieu de cela, ils doivent se trouver dans un sous-dossier dans \Mes documents. En outre, vous ne devez pas placer de données d’application temporaires dans \Program Files ou \Mes documents. Au lieu de cela, il doit être placé dans le dossier Données de l’application (CSIDL_LOCAL_APPDATA).

Plus précisément, il existe deux scénarios que chaque jeu doit gérer :

Scénario 1 : Fichiers qui n’ont pas besoin d’être consultés ou modifiés par les utilisateurs

Un exemple classique est le fichier de configuration du jeu, les fichiers temporaires et les fichiers de cache de jeu. Ces fichiers sont généralement conservés dans le dossier Données d’application. Pour obtenir ce chemin d’accès au dossier, appelez la fonction SHGetFolderPath avec CSIDL_APPDATA ou CSIDL_LOCAL_APPDATA, comme illustré dans l’exemple de code suivant.

#include <shlobj.h>
#include <strsafe.h>

#define APPNAME L"MyApp"

WCHAR wszPath[MAX_PATH];

// Local Application Data
SHGetFolderPath( hWnd, CSIDL_LOCAL_APPDATA, NULL, SHGFP_TYPE_CURRENT, wszPath );
StringCchCatW( wszPath, MAX_PATH, L"\\" );
StringCchCatW( wszPath, MAX_PATH, APPNAME );

// Create the folder wszPath
// Then create files in wszPath
// Roaming Application Data
SHGetFolderPath( hWnd, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, wszPath );
StringCchCatW( wszPath, MAX_PATH, L"\\" );
StringCchCatW( wszPath, MAX_PATH, APPNAME );

// Create the folder wszPath
// Then create files in wszPath

La différence entre les dossiers de données d’application locales et itinérantes est que sur Windows 2000 et Windows XP, le contenu itinérant est copié vers et depuis le serveur pendant le processus d’ouverture de session/déconnexion, tandis que le contenu local n’est pas. Pour la plupart des jeux, les données d’application locales sont suffisantes.

Scénario 2 : Fichiers qui doivent être consultés ou modifiés par les utilisateurs

Un exemple classique serait les fichiers de jeu enregistrés d’un utilisateur. Stockez les fichiers dans le dossier de document de l’utilisateur afin qu’ils soient facilement visibles par l’utilisateur. Une application obtient le chemin du dossier de document de l’utilisateur en appelant SHGetFolderPath avec CSIDL_PERSONAL, comme le montre l’exemple de code suivant :

#include <shlobj.h>
#include <strsafe.h>

#define APPNAME L"MyApp"

WCHAR wszPath[MAX_PATH];

SHGetFolderPath( hWnd, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, wszPath );
StringCchCatW( wszPath, MAX_PATH, L"\\" );
StringCchCatW( wszPath, MAX_PATH, APPNAME );

// Create the folder wszPath
// Then create files in wszPath

Parfois, un jeu peut avoir besoin de stocker des fichiers que tous les utilisateurs sont censés voir et utiliser. L’un des exemples est l’enregistrement de score élevé, où tous les utilisateurs écrivent dans le même fichier d’enregistrement afin que les scores élevés soient conservés à l’échelle du système au lieu d’un score élevé distinct pour chaque utilisateur. D’autres exemples sont des cartes téléchargées, des missions et des modifications de jeu. S’ils sont partagés, un seul utilisateur doit les télécharger au lieu de chaque utilisateur. Dans ce scénario, utilisez le dossier de document sous le dossier de profil partagé, comme illustré dans le code suivant.

#include <shlobj.h>
#include <strsafe.h>

#define APPNAME L"MyApp"

WCHAR wszPath[MAX_PATH];

SHGetFolderPath( hWnd, CSIDL_COMMON_DOCUMENTS, NULL, SHGFP_TYPE_CURRENT, wszPath );
StringCchCatW( wszPath, MAX_PATH, L"\\" );
StringCchCatW( wszPath, MAX_PATH, APPNAME );

// Create the folder wszPath
// Then create files in wszPath

Accès au Registre pour les comptes d’utilisateur Least-Privileged

Il est courant que les applications utilisent le registre Windows pour stocker des informations. À l’instar de l’accès aux fichiers, des comptes d’utilisateur administrateur et des comptes d’utilisateur avec des privilèges minimum n’ont pas la même autorisation sur le Registre. Pour les comptes d’utilisateur avec des privilèges minimum, l’ensemble du nœud HKEY_LOCAL_MACHINE est en lecture seule. Par exemple, un jeu peut lire les informations de configuration par défaut, mais il ne peut pas écrire de nouvelles informations sur ce nœud. Par conséquent, les jeux s’exécutant en mode utilisateur avec des privilèges minimum qui doivent écrire dans le Registre devront utiliser le nœud HKEY_CURRENT_USER pour stocker les informations par utilisateur, comme illustré dans le code suivant.

#define APP_REGISTRY_KEY_PATH L"Software\\MyCompany\\MyApp"

LONG lRetVal;
HKEY hKey;

lRetVal = RegCreateKeyExW( HKEY_CURRENT_USER,
                           APP_REGISTRY_KEY_PATH,
                           0,
                           NULL,
                           REG_OPTION_NON_VOLATILE,
                           KEY_WRITE|KEY_READ,
                           NULL,
                           &hKey,
                           NULL );

if( ERROR_SUCCESS == lRetVal )
{
    // Store information in hKey
}

Il est important de noter qu’au cours de l’installation, les informations de Registre doivent être écrites dans HKEY_LOCAL_MACHINE, et non HKEY_CURRENT_USER. En effet, la personne qui exécute l’installation est généralement un administrateur et peut ne pas être la seule personne à utiliser le programme. Dans ce cas, l’écriture dans HKEY_CURRENT_USER rend les informations indisponibles pour d’autres utilisateurs. Il ne s’agit généralement pas d’un problème, car les informations écrites dans le Registre pendant l’installation sont les paramètres de configuration et par défaut qui s’appliquent à chaque utilisateur du programme.

Lors de la désinstallation du jeu, un effort supplémentaire est nécessaire pour supprimer chaque valeur que le jeu a écrite dans le Registre. Étant donné que le programme de désinstallation est exécuté par une seule personne, généralement l’administrateur, la suppression des informations pertinentes dans HKEY_LOCAL_MACHINE et HKEY_CURRENT_USER ne supprime pas les valeurs pour d’autres utilisateurs. Une façon de supprimer les informations par utilisateur dans le Registre consiste à énumérer la racine hive du registre HKEY_USERS. Chaque sous-clé sous HKEY_USERS correspond à la ruche HKEY_CURRENT_USER pour un utilisateur particulier sur le système. En énumérant HKEY_USERS et en supprimant les informations spécifiques au jeu sous chaque sous-clé, le désinstalleur peut s’assurer qu’aucune information n’est laissée derrière elle.

Mise à jour corrective avec des comptes d’utilisateur Least-Privileged

La mise à jour corrective d’un jeu implique la mise à jour des fichiers du jeu. Par conséquent, il nécessite généralement un accès en écriture au dossier du programme du jeu. La mise à jour corrective d’un jeu est un processus simple lorsqu’il est effectué par un administrateur, car il dispose d’un accès illimité au dossier du programme du jeu. À l’inverse, il a traditionnellement été difficile, s’il n’est pas impossible, pour un utilisateur le moins privilégié de corriger les jeux en raison de la restriction d’accès. À présent, Windows Programme d’installation a été amélioré pour rendre possible la mise à jour corrective des comptes d’utilisateur avec des privilèges minimum. Pour tirer parti de cette fonctionnalité, les jeux sont encouragés à utiliser Windows Programme d’installation pour l’installation et la mise à jour corrective.

À compter de Windows Installer 3.0, les correctifs d’application peuvent être appliqués par des utilisateurs disposant de privilèges minimum lorsque certaines conditions sont remplies. Ces conditions sont les suivantes :

  • L’application a été installée à l’aide de Windows Installer 3.0.
  • L’application a été installée à l’origine par ordinateur.
  • L’application est installée à partir d’un support amovible, tel qu’un CD-ROM ou un disque vidéo numérique (DVD).
  • Les correctifs sont signés numériquement par un certificat identifié par le package d’installation d’origine (fichier .msi).
  • Les correctifs peuvent être validés par rapport à la signature numérique.
  • Le package d’installation d’origine n’a pas désactivé la mise à jour corrective du compte d’utilisateur au moins privilégié.
  • L’administrateur système n’a pas désactivé la mise à jour corrective du compte d’utilisateur au moins privilégié via la stratégie système.

Normalement, un utilisateur moins privilégié ne peut pas modifier les fichiers de programme d’un jeu. Toutefois, lorsque les conditions ci-dessus sont remplies et que la mise à jour corrective LUA est activée, Windows programme d’installation peut mettre à jour les fichiers du jeu afin que l’utilisateur obtienne la dernière version.

Notes

Les informations contenues dans cet article concernent le produit logiciel préversion, qui peut être sensiblement modifié avant sa première version commerciale. En conséquence, les informations peuvent ne pas décrire ou refléter avec précision le produit logiciel lors de la première publication commerciale. Cet article est fourni uniquement à des fins d’information, et Microsoft ne garantit aucune garantie, explicite ou implicite, en ce qui concerne cet article ou les informations contenues dans celui-ci.