Spielen mit Least-Privileged Benutzerkonten

  • Artikel

In diesem Artikel wird beschrieben, wie Spieleentwickler Microsoft Windows Spiele erstellen können, die gut mit wenigsten privilegierten Benutzerkonten funktionieren (auch bekannt als eingeschränkte Benutzerkonten).

Einführung

Windows verwaltet seine Benutzer mit Konten. Heute teilen mehr als achtzig Prozent der Computerbenutzer ihren Computer mit anderen Familienmitgliedern. Wenn mehrere Benutzer einen Windows Computer freigeben, werden mehrere Benutzerkonten erstellt, und jeder Benutzer meldet sich mit einem einzelnen Konto an, um auf den Computer zuzugreifen. Mit dem zunehmenden Bewusstsein für Sicherheit betreiben mehr Menschen ihre Computer mit wenigsten privilegierten Benutzerkonten, auch bekannt als eingeschränkte Benutzerkonten, die keine vollständige Kontrolle über das System haben. Administratorkonten verfügen in der Regel über uneingeschränkten Zugriff auf jeden Teil des Computers. Dies kann sich auf die Funktionsweise von Windows basierten Spielen auswirken.

Es gibt zusätzliche Vorteile für Spieleentwickler, die ihre Spiele schreiben, um mit wenigsten privilegierten Benutzerkonten zu arbeiten. In Windows Vista und später werden mindestens privilegierte Benutzerkonten erzwungen, was bedeutet, dass jedes Konto im System, mit Ausnahme des lokalen Administrators, ein mindestens privilegiertes Benutzerkonto ist. Dies wirkt sich darauf aus, wie Spiele, die nicht der Richtlinie (Legacyanwendungen) folgen, auf Windows Vista und höher ausgeführt werden. Wenn eine Anwendung beispielsweise versucht, in einen Ordner oder einen Registrierungswert zu schreiben, auf den sie nicht berechtigt ist, wird der Dateizugriff auf einen virtuellen Dateispeicher für den Benutzer umgeleitet. Dieser virtuelle Dateispeicher befindet sich in einem Ordner, zu dem der Benutzer Schreibzugriff hat. Dieses Verhalten scheint möglicherweise nicht so katastrophal zu sein, wie das Schreibversuch nicht gerade fehlschlägt; Anwendungen, die virtualisierte Dateien erstellen, verwechseln benutzer jedoch möglicherweise, da Dateien nicht an den Speicherort geschrieben werden, den Benutzer erwarten. Spiele, die beispielsweise Hochbewertungsdateien in denselben Ordner wie der ausführbare Ordner schreiben, schreiben diese Dateien stattdessen in einen virtualisierten Ordner. Daher kann ein Benutzer die hohe Bewertung eines anderen Benutzers nicht sehen, da jeder Benutzer über einen separaten virtualisierten Dateispeicher verfügt.

Spiele, die den Richtlinien in diesem Artikel folgen, werden mit wenigsten privilegierten Benutzerkonten ausgeführt und somit die Kompatibilität mit Windows Vista und höher beibehalten.

Dateizugriff für Least-Privileged Benutzerkonten

Windows unterstützt zwei Dateisysteme: FAT32 und NTFS. FAT32 ist ein älteres Dateisystem, das nur für Abwärtskompatibilität unterstützt wird; NTFS unterstützt leistungsfähigere und robustere Dateiberechtigungen. Die Verwendung von NTFS wird erweitert, da Händler neue Computer mit Windows vorinstalliert auf einer NTFS-partitionierten Festplatte versenden. Auf einem NTFS-basierten Windows XP-System verfügen Benutzer mit mindestens privilegierten Benutzerkonten nur über eingeschränkten Zugriff auf mehrere Ordner. Sie hätten jedoch vollständigen Zugriff auf ein FAT32-basiertes Windows XP-System.

In der folgenden Tabelle wird der Standardspeicherort dieser Ordner und deren Berechtigungen aufgelistet.

Pfad Ordnerinhalt Lesen Schreiben Erstellen/Löschen
<Laufwerk>:\Windows Das Windows Betriebssystem X
<Laufwerk>:\Programmdateien Ausführbare Anwendungsdateien X
<Laufwerk>:\Dokumente und Einstellungen\Benutzername* Dateien jedes Benutzers X X X
<Laufwerk>:\Dokumente und Einstellungen\Alle Benutzer Alle Benutzerdateien X X X

 

* Benutzername ist der Anmeldename des Benutzers.

In einem am wenigsten privilegierten Benutzerkonto können Sie Dateien in einem Ordner lesen, schreiben, löschen und löschen: Dokumente und Einstellungen\Benutzername oder Dokumente und Einstellungen\Alle Benutzer.

Dies bedeutet, dass Sie Spiele nicht in \Programmdateien speichern sollten, sondern sie sollten in einem Unterordner in \Meine Dokumente wechseln. Außerdem sollten Sie keine temporären Anwendungsdaten in \Programmdateien oder \Meine Dokumente platzieren, sondern stattdessen im Ordner "Anwendungsdaten" (CSIDL_LOCAL_APPDATA).

Insbesondere gibt es zwei Szenarien, die jedes Spiel behandeln sollte:

Szenario 1: Dateien, die nicht von Benutzern angezeigt oder geändert werden müssen

Ein typisches Beispiel wäre die Konfigurationsdatei des Spiels, temporäre Dateien und Spielcachedateien. Diese Dateien werden in der Regel im Ordner "Anwendungsdaten" gespeichert. Um diesen Ordnerpfad abzurufen, rufen Sie die FUNKTION SHGetFolderPath mit CSIDL_APPDATA oder CSIDL_LOCAL_APPDATA auf, wie im folgenden Codebeispiel dargestellt.

#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

Der Unterschied zwischen lokalen und Roaming-Anwendungsdatenordnern besteht darin, dass auf Windows 2000 und Windows XP Roaminginhalte während des Anmelde-/Abmeldevorgangs in den Server kopiert werden, während der lokale Inhalt nicht vorhanden ist. Für die meisten Spiele ist lokale Anwendungsdaten ausreichend.

Szenario 2: Dateien, die von Benutzern angezeigt oder geändert werden müssen

Ein typisches Beispiel wäre das gespeicherte Spieldateien eines Benutzers. Store die Dateien im Dokumentordner des Benutzers so, dass sie für den Benutzer leicht sichtbar sind. Eine Anwendung ruft den Dokumentordnerpfad des Benutzers ab, indem SHGetFolderPath mit CSIDL_PERSONAL aufgerufen wird, wie im folgenden Codebeispiel gezeigt wird:

#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

Manchmal muss ein Spiel Dateien speichern, die alle Benutzer anzeigen und verwenden möchten. Ein Beispiel ist der Datensatz mit hoher Bewertung, in dem alle Benutzer in die gleiche Datensatzdatei schreiben, sodass hohe Bewertungen systemweit beibehalten werden, anstatt eine separate Hohe Bewertung für jeden Benutzer zu erzielen. Weitere Beispiele sind heruntergeladene Karten, Missionen und Spieländerungen. Wenn diese freigegeben werden, muss nur ein Benutzer sie anstelle jedes Benutzers herunterladen. Verwenden Sie in diesem Szenario den Dokumentordner unter dem freigegebenen Profilordner, wie im folgenden Code gezeigt.

#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

Registrierungszugriff für Least-Privileged Benutzerkonten

Es ist üblich, dass Anwendungen die Windows Registrierung verwenden, um Informationen zu speichern. Ähnlich wie dateizugriff, Administrator- und mindestens privilegierte Benutzerkonten verfügen nicht über die gleichen Berechtigungen für die Registrierung. Für mindestens privilegierte Benutzerkonten ist der gesamte HKEY_LOCAL_MACHINE Knoten schreibgeschützt. Beispielsweise kann ein Spiel die Standardkonfigurationsinformationen lesen, aber möglicherweise keine neuen Informationen in diesen Knoten schreiben. Daher müssen Spiele, die im minimal privilegierten Benutzermodus ausgeführt werden, die in die Registrierung schreiben müssen, den HKEY_CURRENT_USER Knoten verwenden, um benutzerbezogene Informationen zu speichern, wie im folgenden Code dargestellt.

#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
}

Während der Installation sollten Registrierungsinformationen nicht HKEY_CURRENT_USER auf HKEY_LOCAL_MACHINE geschrieben werden. Dies liegt daran, dass die Person, die die Installation ausführt, in der Regel ein Administrator ist und möglicherweise nicht die einzige Person ist, die das Programm verwendet. In dieser Situation schreibt HKEY_CURRENT_USER die Informationen für andere Benutzer nicht zur Verfügung. Dies ist in der Regel kein Problem, da die Informationen, die während der Installation in die Registrierung geschrieben wurden, die Konfigurations- und Standardeinstellungen sind, die für jeden Benutzer des Programms gelten.

Beim Deinstallieren des Spiels ist zusätzliche Anstrengungen erforderlich, um jeden Wert zu entfernen, den das Spiel in die Registrierung geschrieben hat. Da die Deinstallation von einer Person ausgeführt wird, wird der Administrator in der Regel einfach die relevanten Informationen in HKEY_LOCAL_MACHINE löschen und HKEY_CURRENT_USER werte für andere Benutzer nicht entfernen. Eine Möglichkeit zum Entfernen der Informationen pro Benutzer in der Registrierung besteht darin, den HKEY_USERS Registrierungsstrukturstamm aufzählen zu können. Jeder Unterschlüssel unter HKEY_USERS entspricht der HKEY_CURRENT_USER Struktur für einen bestimmten Benutzer im System. Durch Aufzählen von HKEY_USERS und Entfernen der spielspezifischen Informationen unter jedem Unterschlüssel kann der Deinstallierer sicherstellen, dass keine Informationen zurückgelassen werden.

Patchen mit Least-Privileged Benutzerkonten

Das Patchen eines Spiels umfasst das Aktualisieren der Dateien des Spiels. Daher erfordert es in der Regel den Schreibzugriff auf den Programmordner des Spiels. Das Patchen eines Spiels ist ein einfacher Prozess, wenn es von einem Administrator durchgeführt wird, da sie uneingeschränkten Zugriff auf den Programmordner des Spiels haben. Umgekehrt ist es traditionell schwierig gewesen, für einen wenigsten privilegierten Benutzer, Spiele aufgrund der Zugriffseinschränkung zu patchen. Jetzt wurde Windows Installer erweitert, um das Patchen von wenigsten privilegierten Benutzerkonten möglich zu machen. Um dieses Feature zu nutzen, werden Spiele empfohlen, Windows Installer für die Installation und Das Patchen zu nutzen.

Ab Windows Installer 3.0 können Anwendungspatches von mindestens privilegierten Benutzern angewendet werden, wenn bestimmte Bedingungen erfüllt sind. Diese Bedingungen sind:

  • Die Anwendung wurde mithilfe Windows Installer 3.0 installiert.
  • Die Anwendung wurde ursprünglich pro Computer installiert.
  • Die Anwendung wird von Wechselmedien installiert, z. B. CD-ROM oder digitale Videodatenträger (DVD).
  • Die Patches werden digital von einem Zertifikat signiert, das vom ursprünglichen Installationsprogrammpaket (.msi Datei) identifiziert wird.
  • Die Patches können anhand der digitalen Signatur überprüft werden.
  • Das ursprüngliche Installationsprogrammpaket hat das Patching der geringsten Privilegierten Benutzerkonten nicht deaktiviert.
  • Der Systemadministrator hat das Patchen des geringsten Privilegierten Benutzerkontos über die Systemrichtlinie nicht deaktiviert.

Normalerweise kann ein am wenigsten privilegierter Benutzer die Programmdateien eines Spiels nicht ändern. Wenn jedoch die oben genannten Bedingungen erfüllt sind und LUA-Patching aktiviert ist, kann Windows Installer die Dateien des Spiels aktualisieren, damit der Benutzer die neueste Version erhält.

Hinweis

Die in diesem Artikel enthaltenen Informationen beziehen sich auf vorab veröffentlichte Softwareprodukte, die vor der ersten kommerziellen Version erheblich geändert werden können. Dementsprechend können die Informationen das Softwareprodukt bei der ersten kommerziellen Veröffentlichung nicht genau beschreiben oder widerspiegeln. Dieser Artikel wird nur für Informationszwecke bereitgestellt, und Microsoft übernimmt keine Garantien, ausdrücklich oder implizit, in Bezug auf diesen Artikel oder die darin enthaltenen Informationen.