SemaphoreSecurity-Klasse

Ein SemaphoreSecurity-Objekt gibt Zugriffsrechte für ein benanntes Systemsemaphor an. Darüber hinaus wird angegeben, wie Zugriffsversuche überwacht werden. Zugriffsrechte auf das Semaphor werden als Regeln ausgedrückt, wobei jede Zugriffsregel durch ein SemaphoreAccessRule-Objekt dargestellt wird. Jede Überwachungsregel wird durch ein SemaphoreAuditRule-Objekt dargestellt.

Dadurch wird das zugrunde liegende Sicherheitssystem von Windows gespiegelt, in dem alle sicherungsfähigen Objekte maximal über jeweils eine freigegebene Zugriffssteuerungsliste (DACL – Discretionary Access Control List) verfügen, die den Zugriff auf das gesicherte Objekt steuert, sowie maximal eine Systemzugriffssteuerungsliste (SACL – System Access Control List), die angibt, welche Zugriffsversuche überwacht werden. Bei DACL und SACL handelt es sich um geordnete Listen von ACEs (Access Control Entries, Zugriffssteuerungseinträge), die den Zugriff und die Überwachung für Benutzer und Gruppen angeben. Ein SemaphoreAccessRule-Objekt oder SemaphoreAuditRule-Objekt kann u. U. mehrere ACEs darstellen.

Hinweis
Ein Semaphore-Objekt kann ein lokales Semaphor oder ein benanntes Systemsemaphor darstellen. Windows-Zugriffssteuerungssicherheit ist nur für benannte Systemsemaphore von Bedeutung.

Die Klassen SemaphoreSecurity, SemaphoreAccessRule und SemaphoreAuditRule blenden die Implementierungsdetails von ACLs und ACEs aus. Mithilfe dieser Klassen können Sie die siebzehn verschiedenen ACE-Typen und die komplexen Aufgaben bei der ordnungsgemäßen Verwaltung der Vererbung und der Weitergabe von Zugriffsrechten ignorieren. Diese Objekte sollen darüber hinaus auch die folgenden häufigen Zugriffssteuerungsfehler verhindern:

• Das Erstellen einer Sicherheitsbeschreibung mit einer NULL-DACL. Mithilfe eines NULL-Verweises auf eine DACL können beliebige Benutzer einem Objekt Zugriffsregeln hinzufügen. Dadurch werden Denial-of-Service-Angriff ermöglicht. Ein neues SemaphoreSecurity-Objekt beginnt immer mit einer leeren DACL, wodurch allen Benutzern der Zugriff verweigert wird.

• Das Verstoßen gegen die kanonische Reihenfolge der ACEs. Wenn die ACE-Liste in der DACL keine kanonische Reihenfolge aufweist, erhalten Benutzer möglicherweise unbeabsichtigt Zugriff auf das gesicherte Objekt. Verweigerte Zugriffsrechte müssen z. B. immer vor gewährten Zugriffsrechten angeordnet werden. SemaphoreSecurity -Objekte behalten intern die richtige Reihenfolge bei.

• Das Bearbeiten von Sicherheitsbeschreibungsflags, das nur vom Ressourcen-Manager gesteuert werden soll.

• Das Erstellen ungültiger Kombinationen von ACE-Flags.

• Das Bearbeiten von geerbten ACEs. Vererbung und Weitergabe werden vom Ressourcen-Manager als Reaktion auf die von Ihnen vorgenommenen Änderungen an den Zugriffs- und Überwachungsregeln behandelt.

• Das Einfügen von bedeutungslosen ACEs in ACLs.

Die einzigen von .NET-Sicherheitsobjekten nicht unterstützten Funktionen sind gefährliche Aktivitäten. Diese sollten von den meisten Anwendungsprogrammierern vermieden werden. Als gefährliche Aktivitäten gelten u. a.:

• Aufgaben auf niedriger Ebene, die normalerweise vom Ressourcen-Manager ausgeführt werden.

• Das Hinzufügen oder Entfernen von Zugriffssteuerungseinträgen ohne Beibehaltung der kanonischen Reihenfolge.

Um die Windows-Zugriffssteuerungssicherheit für ein benanntes Semaphor zu ändern, rufen Sie mithilfe der Semaphore.GetAccessControl-Methode das SemaphoreSecurity-Objekt ab. Ändern Sie das Sicherheitsobjekt durch Hinzufügen und Entfernen von Regeln, und fügen Sie es dann mithilfe der Semaphore.SetAccessControl-Methode erneut an.

Wichtig
Änderungen an einem SemaphoreSecurity-Objekt wirken sich erst dann auf die Zugriffsebenen des benannten Semaphors aus, wenn die Semaphore.SetAccessControl-Methode aufgerufen wird, um dem benannten Semaphor das geänderte Sicherheitsobjekt zuzuweisen.

Sie können die Zugriffssteuerungssicherheit aus einem Semaphor in ein anderes kopieren, indem Sie mithilfe der Semaphore.GetAccessControl-Methode ein SemaphoreSecurity-Objekt abrufen, das die Zugriffs- und Überwachungsregeln für das erste Semaphor darstellt. Verwenden Sie anschließend die Semaphore.SetAccessControl-Methode oder einen Konstruktor, der ein SemaphoreSecurity-Objekt akzeptiert, um dem zweiten Semaphor diese Regeln zuzuweisen.

Benutzer, die SDDL (Security Descriptor Definition Language) verwenden, können mithilfe der SetSecurityDescriptorSddlForm-Methode Zugriffsregeln für ein benanntes Semaphor festlegen und mithilfe der GetSecurityDescriptorSddlForm-Methode eine Zeichenfolge abrufen, die die Zugriffsregeln im SDDL-Format darstellt. Dies wird nicht für Neuentwicklungen empfohlen.

Hinweis
Sicherheit wird für Synchronisierungsobjekte für Windows 98 oder Windows Millennium Edition nicht unterstützt.

Im folgenden Codebeispiel wird die Aufteilung in Allow-Regeln und in Deny-Regeln veranschaulicht. Außerdem wird die Kombination von Rechten in kompatiblen Regeln dargestellt. Im Beispiel wird ein SemaphoreSecurity-Objekt erstellt. Außerdem werden Regeln hinzugefügt, die dem aktuellen Benutzer eine Reihe von Rechten gewähren und verweigern, und das erhaltene Regelpaar wird angezeigt. Anschließend werden dem aktuellen Benutzer im Beispiel neue Rechte gewährt und das Ergebnis wird angezeigt, das die Zusammenführung der neuen Rechte mit der vorhandenen Allow-Regel darstellt.

Hinweis
In diesem Beispiel wird das Sicherheitsobjekt nicht an ein Semaphore-Objekt angefügt. Beispiele, in denen Sicherheitsobjekte angefügt werden, finden Sie unter Semaphore.GetAccessControl und Semaphore.SetAccessControl.

.NET Framework

.NET Framework Client Profile

Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core-Rolle wird nicht unterstützt), Windows Server 2008 R2 (Server Core-Rolle wird mit SP1 oder höher unterstützt; Itanium wird nicht unterstützt)

Referenz