(0) exportieren Drucken
Alle erweitern

EventWaitHandleSecurity-Klasse

Stellt die für ein benanntes System-WaitHandle übernommene Windows-Zugriffssteuerungssicherheit dar. Diese Klasse kann nicht geerbt werden.

Namespace: System.Security.AccessControl
Assembly: mscorlib (in mscorlib.dll)

public sealed class EventWaitHandleSecurity : NativeObjectSecurity
public final class EventWaitHandleSecurity extends NativeObjectSecurity
public final class EventWaitHandleSecurity extends NativeObjectSecurity
Nicht zutreffend.

Ein EventWaitHandleSecurity-Objekt gibt die Zugriffsrechte für ein benanntes System-WaitHandle sowie die Art der Überwachung von Zugriffsversuchen an. Die Zugriffsrechte für das WaitHandle sind in Regeln formuliert, wobei jede Zugriffsregel durch ein EventWaitHandleAccessRule-Objekt dargestellt wird. Jede Überwachungsregel wird durch ein EventWaitHandleAuditRule-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 EventWaitHandleAccessRule-Objekt oder EventWaitHandleAuditRule-Objekt kann u. U. mehrere ACEs darstellen.

HinweisHinweis:

Ein EventWaitHandle-Objekt kann ein lokales WaitHandle oder ein benanntes System-WaitHandle darstellen. Die Windows-Zugriffssteuerungssicherheit ist nur für benannte System-WaitHandles von Bedeutung.

Die Klassen EventWaitHandleSecurity, EventWaitHandleAccessRule und EventWaitHandleAuditRule 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 EventWaitHandleSecurity-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. Für EventWaitHandleSecurity-Objekte wird die korrekte Reihenfolge intern beibehalten.

  • 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 WaitHandle zu ändern, rufen Sie mithilfe der EventWaitHandle.GetAccessControl-Methode das EventWaitHandleSecurity-Objekt ab. Ändern Sie das Sicherheitsobjekt durch Hinzufügen und Entfernen von Regeln, und fügen Sie es dann mithilfe der EventWaitHandle.SetAccessControl-Methode erneut an.

HinweisWichtig:

Änderungen an einem EventWaitHandleSecurity-Objekt wirken sich erst dann auf die Zugriffsebenen des benannten WaitHandles aus, wenn die EventWaitHandle.SetAccessControl-Methode aufgerufen wird, um dem benannten WaitHandle das geänderte Sicherheitsobjekt zuzuweisen.

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

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

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 EventWaitHandleSecurity-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.

HinweisHinweis:

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

using System;
using System.Threading;
using System.Security.AccessControl;
using System.Security.Principal;

public class Example
{
    public static void Main()
    {
        // Create a string representing the current user.
        string user = Environment.UserDomainName + "\\" + 
            Environment.UserName;

        // Create a security object that grants no access.
        EventWaitHandleSecurity mSec = new EventWaitHandleSecurity();

        // Add a rule that grants the current user the 
        // right to wait on or signal the event.
        EventWaitHandleAccessRule rule = new EventWaitHandleAccessRule(user, 
            EventWaitHandleRights.Synchronize | EventWaitHandleRights.Modify, 
            AccessControlType.Allow);
        mSec.AddAccessRule(rule);

        // Add a rule that denies the current user the 
        // right to change permissions on the event.
        rule = new EventWaitHandleAccessRule(user, 
            EventWaitHandleRights.ChangePermissions, 
            AccessControlType.Deny);
        mSec.AddAccessRule(rule);

        // Display the rules in the security object.
        ShowSecurity(mSec);

        // Add a rule that allows the current user the 
        // right to read permissions on the event. This rule
        // is merged with the existing Allow rule.
        rule = new EventWaitHandleAccessRule(user, 
            EventWaitHandleRights.ReadPermissions, 
            AccessControlType.Allow);
        mSec.AddAccessRule(rule);

        ShowSecurity(mSec);
    }

    private static void ShowSecurity(EventWaitHandleSecurity security)
    {
        Console.WriteLine("\r\nCurrent access rules:\r\n");

        foreach(EventWaitHandleAccessRule ar in 
            security.GetAccessRules(true, true, typeof(NTAccount)))
        {
            Console.WriteLine("        User: {0}", ar.IdentityReference);
            Console.WriteLine("        Type: {0}", ar.AccessControlType);
            Console.WriteLine("      Rights: {0}", ar.EventWaitHandleRights);
            Console.WriteLine();
        }
    }
}

/*This code example produces output similar to following:

Current access rules:

        User: TestDomain\TestUser
        Type: Deny
      Rights: ChangePermissions

        User: TestDomain\TestUser
        Type: Allow
      Rights: Modify, Synchronize


Current access rules:

        User: TestDomain\TestUser
        Type: Deny
      Rights: ChangePermissions

        User: TestDomain\TestUser
        Type: Allow
      Rights: Modify, ReadPermissions, Synchronize
 */

Alle öffentlichen statischen (Shared in Visual Basic) Member dieses Typs sind threadsicher. Bei Instanzmembern ist die Threadsicherheit nicht gewährleistet.

Windows 98, Windows Server 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile für Pocket PC, Windows Mobile für Smartphone, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition

Microsoft .NET Framework 3.0 wird unter Windows Vista, Microsoft Windows XP SP2 und Windows Server 2003 SP1 unterstützt.

.NET Framework

Unterstützt in: 3.0, 2.0
Anzeigen:
© 2014 Microsoft