Jeux avec Least-Privileged comptes d’utilisateur

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

• Introduction
• Accès aux fichiers pour Least-Privileged comptes d’utilisateur
  • Scénario 1 : Fichiers qui n’ont pas besoin d’être consultés ou modifiés par les utilisateurs
  • Scénario 2 : Fichiers qui doivent être consultés ou modifiés par les utilisateurs
• Accès au Registre pour les comptes d’utilisateur Least-Privileged
• Mise à jour corrective avec Least-Privileged comptes d’utilisateur

Introduction

Windows gère ses utilisateurs avec des comptes. Aujourd’hui, plus de quatre-vingts pour cent des utilisateurs d’ordinateurs à 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é, de plus en plus de personnes exploitent leurs ordinateurs avec des comptes d’utilisateur moins privilégiés, également appelés comptes d’utilisateur limité, qui n’ont pas un contrôle total sur le système. Les comptes d’administrateur ont généralement un accès illimité à chaque partie de l’ordinateur. Cela peut affecter le fonctionnement des jeux Windows.

Il existe des avantages supplémentaires pour les développeurs de jeux qui écrivent leurs jeux pour travailler avec les comptes d’utilisateur les moins privilégiés. Dans Windows Vista et les versions ultérieures, les comptes d’utilisateur les moins privilégiés sont appliqués, ce qui signifie que chaque compte sur le système, à l’exception de l’administrateur local, est un compte d’utilisateur moins privilégié. Cela affecte la façon dont les jeux qui ne suivent pas les recommandations (applications héritées) s’exécutent sur Windows Vista et versions ultérieures. Par instance, lorsqu’une application tente d’écrire dans un dossier ou une valeur de Registre pour laquelle elle n’est pas autorisée, l’écriture de fichier est redirigée vers un magasin de fichiers virtuel pour l’utilisateur. Ce magasin de fichiers virtuel résidera dans un dossier auquel l’utilisateur a accès en écriture. Ce comportement peut ne pas sembler aussi catastrophique que l’échec pur et simple de la tentative d’écriture ; toutefois, les applications qui créent des fichiers virtualisés peuvent embrouiller les utilisateurs, car les fichiers ne seront pas écrits dans l’emplacement attendu par les utilisateurs. Par instance, les jeux qui écrivent des fichiers à 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 les comptes d’utilisateur les moins privilégiés et, par conséquent, conservent la compatibilité avec Windows Vista et versions ultérieures.

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

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 fichier plus puissantes et robustes. L’utilisation de NTFS se développe à 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 moins privilégiés n’ont qu’un accès limité à plusieurs dossiers. Toutefois, ils auraient un accès complet sur un système Windows XP basé sur FAT32.

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

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

Dans un compte d’utilisateur moins privilégié, vous pouvez lire, écrire, créer et supprimer des fichiers dans l’un ou l’autre dossier : 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, mais qu’ils doivent se trouver dans un sous-dossier dans \Mes documents. De plus, vous ne devez pas placer les données d’application temporaires dans \Program Files ou \Mes documents, mais elles doivent être placées dans le dossier Données d’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 typique 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 indiqué 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 locaux et itinérants 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, alors que le contenu local ne l’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 typique est les fichiers de jeu enregistrés d’un utilisateur. Stockez les fichiers dans le dossier de documents de l’utilisateur afin qu’ils soient facilement visibles par l’utilisateur. Une application obtient le chemin du dossier de documents 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. Un exemple 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 les cartes téléchargées, les missions et les modifications de jeu. Si ceux-ci 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. Comme pour l’accès aux fichiers, les comptes d’administrateur et d’utilisateur les moins privilégiés n’ont pas la même autorisation sur le Registre. Pour les comptes d’utilisateur à privilèges minimum, l’intégralité du nœud HKEY_LOCAL_MACHINE est en lecture seule. Par instance, un jeu peut lire les informations de configuration par défaut, mais ne peut pas écrire de nouvelles informations sur ce nœud. Par conséquent, les jeux s’exécutant en mode utilisateur le moins privilégié qui doivent écrire dans le Registre devront utiliser le nœud HKEY_CURRENT_USER pour stocker des 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 convient de noter que pendant l’installation, les informations du 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, écrire à HKEY_CURRENT_USER rend les informations indisponibles pour d’autres utilisateurs. Ce n’est généralement pas un problème, car les informations écrites dans le Registre pendant l’installation sont la configuration et les paramètres par défaut qui s’appliquent à chaque utilisateur du programme.

Lors de la désinstallation du jeu, des efforts supplémentaires sont nécessaires 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, il suffit de supprimer les informations pertinentes dans HKEY_LOCAL_MACHINE et HKEY_CURRENT_USER ne supprime pas les valeurs pour les autres utilisateurs. L’un des moyens de supprimer les informations par utilisateur dans le Registre consiste à énumérer les HKEY_USERS racine de ruche du Registre. Chaque sous-clé sous HKEY_USERS correspond à la ruche HKEY_CURRENT_USER d’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 programme de désinstallation peut s’assurer qu’aucune information n’est laissée pour compte.

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

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, voire impossible, pour un utilisateur moins privilégié de corriger les jeux en raison de la restriction d’accès. À présent, Windows Installer a été amélioré pour rendre possible la mise à jour corrective des comptes d’utilisateur les moins privilégiés. Pour tirer parti de cette fonctionnalité, les jeux sont encouragés à utiliser Windows Installer pour l’installation et la mise à jour corrective.

À compter de Windows Installer 3.0, les correctifs d’application peuvent être appliqués par les utilisateurs les moins privilégiés 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 initialement été installée par machine.
• 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 du programme d’installation d’origine (fichier .msi).
• Les correctifs peuvent être validés par rapport à la signature numérique.
• Le package du programme d’installation d’origine n’a pas désactivé la mise à jour corrective du compte d’utilisateur à privilèges minimum.
• L’administrateur système n’a pas désactivé la mise à jour corrective du compte d’utilisateur à privilèges moindres via la stratégie système.

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