Parallel.ForEach () ändert den Identitätswechselkontext

Heute haben wir unsere neu erstellte ASP.NET-Anwendung auf dem Server bereitgestellt, und bald stellten wir fest, dass ein seltsames Sicherheitsproblem die Anwendung zum Absturz brachte. Dies ist eine interne Anwendung und wir verwenden Identitätswechsel, um zu verwalten, wie die Benutzer auf Ressourcen zugreifen. Die Anwendung gibt jedoch eine "Zugriff verweigert" -Ausnahme aus, wenn der Benutzer versucht, auf einen Ordner zuzugreifen, über den er Vollzugriff hat.

Die Ausnahme war in der Tat einAggregateException und wurde in einer Methode geworfen, die @ verwendParallel.ForEach, um über eine Liste und innerhalb des Texts zu listen, versucht es, auf den Ordner zuzugreifen, aber zu diesem Zeitpunkt wird der Identitätswechselkontext geändert und der Arbeitsthread wird als die Identität des Anwendungspools ausgeführt, der keinen Zugriff auf den Ordner hat, daher die Ausnahme .

Um dies zu bestätigen, habe ich mir die Prozessidentität vor und innerhalb des Körpers von @ angeseheParallel.ForEach:

string before = WindowsIdentity.GetCurrent().Name;
Debug.WriteLine("Before Loop: {0}", before);

Parallel.ForEach(myList, currentItem =>
{
    string inside = WindowsIdentity.GetCurrent().Name;
    Debug.WriteLine("Inside Loop: {0} (Worker Thread {1})", inside, Thread.CurrentThread.ManagedThreadId);
});

Wenn ich die App starte, wird Folgendes ausgedruckt:

Before Loop: MyDomain\ImpersonatedUser

Inside Loop: NT AUTHORITY\SYSTEM (Worker Thread 8)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 6)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 7)
Inside Loop: NT AUTHORITY\SYSTEM (Worker Thread 9)
Inside Loop: NT AUTHORITY\SYSTEM (Worker Thread 10)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 7)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 6)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 7)

Wie Sie sehen können, werden einige Threads als imitierte Identität und andere als Anwendungspool ausgeführt (in diesem FallLocalSystem) und es scheint kein Muster zu geben. Das vorherige Bild imCall Stack Fenster geht auch zu dem nicht verwaltetenkernel32.dll, was mich glauben lässt, dass CLR den Kontext nicht überprüft, bevor er an das Betriebssystem delegiert wird.

Eine Idee, warum das passiert? Ist das ein bekanntes Problem / Fehler?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage