Kays Senf

Nach einer relativ kurzen Beta-Phase mit hervorragender Unterstützung der Forenmitglieder ist SuRun 1.2 freigegeben.

Neben der Neuerung, dass SuRun keine Kennworte mehr benötigt oder speichert, läuft es jetzt auch unter Windows Vista bei aktivierter Benutzerkontensteuerung. Dadurch können nun auch unter Vista aus einem echten eingeschränkten Konto Programme mit gehobenen Rechten gestartet werden, ohne ein Administratorkennwort haben zu müssen. 😀

Die volle Liste der Neuerungen ist ziemlich lang.

Als nächstes wird der Quellcode so umgestellt, dass er mit Visual-Studio 2005/2008 kompiliert werden kann.

(Im Folgenden sind Beiträge aus dem SuRun Forum zusammengefasst)

Wenn man „SuRun Explorer“ ausgeführt hatte und dieses Explorer-Fenster noch offen war, konnte man mit „Start->Ausführen ‚Explorer'“ keine neue Instanz des Explorer mehr starten.  😯   Erst, wenn das mit erhöhten Rechten laufende Fenster wieder zu war, ließ sich Explorer wieder mit normalen Rechten starten. Das Problem schien nicht SuRun-Spezifisch zu sein, denn mit SuDown und MachMichadmin hat man es auch.

Mit „Process Explorer“ und „Process Monitor“ fand ich heraus, dass der Explorer zwar startet, sich aber sofort wieder selbst beendet. Vor der Fertigstellung von SuRun 1.2 habe ich mir die Funktionsweise von Explorer mal näher angesehen.

Unter Windows „ab Vista“ gibt es den Explorer-Kommandozeilenparameter „/SEPARATE“. Damit startet Explorer immer einen separaten Prozess. SuRun benutzt den Parameter ab Version 1.2.0.0.

Unter Windows „vor Vista“ sendet ein neu gestarteter Explorer seine Kommandozeile per Windows Nachricht an einen bereits laufenden.

Ist „Ordnerfenster in eigenen Prozess starten“ AUS, sendet der neue Explorer die Nachricht an den Desktop, wartet, bis der Desktop diese Nachricht verarbeitet hat und beendet sich dann.

Ist „Ordnerfenster in eigenen Prozess starten“ EIN, sucht Explorer nach einem Fenster mit dem Klassennamen „Proxy Desktop„. Findet er kein solches Fenster, erstellt er selbst eins und läuft weiter. Findet Explorer ein Fenster der Klasse „Proxy Desktop„, sendet der neue Explorer seine Kommandozeile per Windows-Nachricht an dieses Fenster, wartet, bis es die Nachricht verarbeitet hat und beendet sich dann.

Deswegen sind trotz „Ordnerfenster in eigenen Prozess starten“ EIN immer maximal zwei Explorer.exe im System zu finden.

Warum geht das Starten neuer eingeschränkter Explorer nicht, nachdem ein administrativ laufender offen ist?

Der neu gestartete, eingeschränkte Explorer sendet seine Kommandozeile per Nachricht an den bereits laufenden.
So weit ok.
Dann versucht er zu warten, bis der „alte“, administrativ laufende Explorer die Nachricht verarbeitet hat.
Das macht er, indem er versucht herauszufinden, dass der „alte“ Explorer auf Benutzereingaben wartet (OpenProcess, WaitForInputIdle).
Dazu (OpenProcess) hat er jedoch keine Berechtigung.
Dann beendet der „neue“ Explorer sich sofort und der „alte“ kann die Kommandozeile nicht mehr aus dem „neuen“ auslesen. Dadurch scheint es, dass kein neuer Explorer mehr startet.

Wie kann man trotzdem einen neuen Explorer starten?

Man muss,

• „Ordnerfenster in eigenen Prozess starten“ auf EIN setzen,
• alle Fenster mit dem Klassennamen „Proxy Desktop“ (WM_CLOSE) schließen.
• den „neuen“ Explorer starten
• warten, bis der „neue“ Explorer sein „Proxy Desktop“ Fenster erstellt hat und es schließen (WM_CLOSE)
• „Ordnerfenster in eigenen Prozess starten“ wieder auf AUS setzen, wenn das vorher aus war

Vorgestern wollte mein virtuell laufendes Vista folgendes:

Hmmm… 😯

Wo ist der verdammte „Fortsetzen“ Knopf und wo kann ich irgend ein Kennwort eingeben?

War Vista sauer, dass es aus der VM nicht raus durfte?

Aber erstaunt war ich vor Allem als Programmierer: So etwas muss jemand wirklich programmiert haben, den Microsoft dafür bezahlt hat…

Der Christian schreibt eine Bibliothek zum Ausführen mit administrativen Rechten unter Delphi. Er hat mich mit der Nase in zwei Probleme gestukt, die Microsoft selbst verursacht.

Startet man einen Prozess mit CreateProcessWithLogonW, wird er bei der Abmeldung des Benutzers vom Dienst „Sekundäre Anmeldung“ auch beendet.

So weit, ok.

Nur erstens benutzt der Dienst „Sekundäre Anmeldung“ TerminateProcess(), um alle mit CreateProcessWithLogonW gestarteten Prozesse zu beenden. Das ist schon ziemlich übel, denn die Programme können so weder temporär angelegte Dateien löschen, noch fragen, ob der Benutzer vor der Abmeldung geänderte Daten speichern will. Die Prozesse werden aus dem Speicher entladen und Schluss.

Viel schlimmer ist, wenn man den Dienst „Sekundäre Anmeldung“ beendet bzw. neu startet. Dann bleiben bei der Abmeldung des Benutzers alle mit CreateProcessWithLogonW gestarteten Prozesse offen. Meldet sich danach ein Gast am System an, sieht der dann die noch laufenden Prozesse! Das kann man mit von SuRun gestarteten Prozessen sehr leicht nachvollziehen!

Oh Mann!

Schlimm genug, dass Microsoft ein RunAs zur Verfügung stellt, dem man mit Gastrechten Administratorenkennwörter entlocken kann. Aber jetzt auch noch das! Wie immer: Wenn man will, dass es wirklich funktioniert, muss man es selbst machen.

WindowStations und Desktops existieren in Windows NT seit Anbeginn, Zugriffskontrollisten auch. SuRun könnte völlig überflüssig sein, schon in Windows NT 3. Warum baut einer der reichsten Softwarekonzerne gerade bei der Sicherheit immer wieder so einen Bockmist?

Ich werde SuRun auf LSALogonUser umstricken. Hoffentlich ist da kein Bug drin!

Wenigstens braucht SuRun mit LSALogonUser den Benutzer nicht mehr in die Administratorengruppe eintragen. Der Start des Benutzerprozesses der den gehobenen Prozess startet fällt dann auch weg. Allerdings muss SuRun alle gestarteten Prozesse bei der Abmeldung des Benutzers selbst beenden… Irgend was ist immer!

Dieses Jahr ist unser Garten zu sehr von Insekten bewohnt. Besonders die kleinen Borrelioseverteiler nerven arg. Einmal über die Wiese gelaufen, hat man zwei Unterschlupf suchende Krabbeltiere anhaften.

Gestern hat meine Frau eine Zeckenfahne gebastelt und ist damit ca. eine halbe Stunde über die (ca. 500m²) Grünflächen geflitzt. Als Resultat haben sich vierzehn Blutsauger vom weißen Tuch mitreißen lassen und wurden fachmännisch per Flammenwerfer entsorgt.

Drei weitere Zecken haben wir beim Krabbeln erwischt, keine hat es geschafft, Fuß zu fassen.

Mein Sohnemann, das ist der hier

hat es heute geschafft, das zu vereinigen:

Ich habe es erst bemerkt, als es schon stank.

Zum Glück ist keinem etwas passiert. Nicht einmal dem Telefon 😎 !

Nach dem Abschalten des Toasters konnte ich das Mobilteil gar nicht anfassen, so heiß war es.

Es hat Blessuren auf der Rückseite:

und auch das Display ist etwas „vermilcht“.

Aber alles funktioniert noch perfekt!

Sieben Jahre alt, getoastet und läuft trotzdem noch. Meine Nokia Mobilofone haben da schneller aufgegeben 😉

Tja, Siemens baut nicht immer Mist