Sessions unter Windows

« | 05 Dec 2018 | »

Eine “Sitzung” auch als “Session” bekannt, kann je nach Applikationssicht alles mögliche sein.

Windows nutzte den Begriff schon in seinen Anfängen.

This will end your Windows Sessions.
(OK) (Cancel)

Doch mit NT 4 und der Einführung von Terminal-Services, hat der Begriff auch programmatisch Bedeutung.

---

Dass Windows anfangs ausschließlich auf GUIs ausgelegt war, wurde mit der Dienste

• Architektur von NT zu einem Problem. Auch dass mehrere Benutzer mit unterschiedlichen Rechten Programme parallel ausführen können sollten war in Sachen Kompatibilität mit der alten Windows API (aus der 16 bit Zeit) problematisch.

Terminal Service Sessions

Terminal Services erlauben, dass mehrere Benutzer gleichzeitig grafische “Sitzungen” starten, die von einander isoliert laufen. Die Idee war, dass Programme wie Office nur auf einem Terminal Server installiert waren und die Benutzer mit Thin-Clients die Programme über das Netzwerk nutzen konnten.

Eine Session ist in Windows daher eine isolierte Anmeldung eines Benutzers mit seiner Umgebung und seinen nutzbaren Programmen … also alles, was man auf seinem Desktop sehen kann.

Wenn wir uns also am PC einloggen, startet eine Session und alle Programme, die dann starten, sind mit genau dieser Session verbunden.
Auf Terminal Servern können dass natürlich mehrere gleichzeitig sein und daher ist es wichtig, dass keine Programm aus Session A an Daten aus Session B gelangt.

Uns Programmierern wird über die Remote Desktop Dienste Einblick in die laufenden Sessions gewährt, selbst wenn der Remote Desktop gar nicht genutzt wird. Die APIs beginnen immer noch mit WTS... für Windows Terminal Services.

Window Station und Desktops

Innerhalb einer Session gibt es dann noch weiter Hierarchien für die Isolation bzw. Separation von Daten.

Die erste Ebene ist die der Window Stations. Jeder Prozess ist genau einer Window Station zu geordnet, von der er Zugang zum Clipboard oder zu den Fensterklassen erhält.

Der Standard Windows Login Dienst erzeugt immer nur eine Window Station namens winsta0 und weitere Prozesse erben diese Umgebung.

Innerhalb einer Window Station kann es einen oder mehrere Desktops geben. Es kann immer nur ein Desktop aktiv sein (also angezeigt werden), doch es ist möglich zwischen diesen umzuschalten.

Die bekannteste Nutzung ist der Sicherheitsdialog von Windows seit Vista, wenn wir Aktionen bestätigen sollen. Hier wechselt Windows vom Standard-Desktop auf einen anderen, wo nur der Dialog eingeblendet wird. (Es sieht nur so aus, als wären wir am alten Desktop.)

Seit Windows 2000 gab es Tools, mit denen man mehrere Desktops parallel betreiben und zwischen ihnen wechseln konnte. Sysinternals Desktops war eines davon.

Erst mit Windows 10 wurde dieses Feature offiziell von der Windows UI selbst bereitgestellt, obwohl es schon seit 20 Jahren möglich war, dies per API umzusetzen.

Während Window Stations mit Prozessen assoziiert sind, werden Desktops mit Threads verknüpft. Ein Thread kann daher immer nur einem Desktop zugeordnet sein und nur dort kann er Fenster betreuen.
Es ist nicht möglich Fenster von einem Desktop auf den anderen zu zaubern, so wie es auch nicht gestattet ist, dass ein Thread sich an anderen Desktop bindet, wenn er ein erzeugtes Fenster verwaltet.

Zusammenfassung

• Windows Session
  Beginnt mit dem Login eines Benutzers
  • Window Station
    Stellt für Prozesse gemeinsam genutzte Objekte wie Clipboard und ATOM-Tabellen bereit
    • Desktops
      Stellen für Threads eine Umgebung für das Verwalten von Fenstern bereit

Windows Services laufen in der für Benutzer unerreichbaren Session “0”. Früher (NT, 2000, XP) war Session 0 dem lokalen Login vorbehalten, womit Services und Benutzerprogramme nur durch Window Stations und Desktops getrennt waren. Windows Vista machte mit dieser Sicherheitslücke Schluss und zwingt Benutzerlogins immer in separate Sessions mit IDs größer 0.

Normalerweise kümmern wir uns als Programmierer um diese Details nicht, weil die Zugehörigkeit zu Session, Window Station und Desktop vom Elternprozess vererbt wird.

Schreib man aber Software, wie z.B.: VNC, dann ist es erforderlich von einem Steuerdienst, der in der isolierten Service-Session läuft, einen neuen Prozess in der Benutzer-Session zu starten, um dort den Bildschirm abfotografieren zu können.

Services in Session 0 mit LOCALSYSTEM Rechten sind somit das einzige, was die Session-Isolation durchbrechen kann.

Das GATE Projekt bildet in seiner API diese Möglichkeit auch nach. Hier wurde der zusätzliche Parameter location in der Prozess-API eingeführt, mit der ein Dienstprozess seine Kinder in andere Session injizieren kann.