CodeSite Studio 5.3.2 funktioniert plötzlich nur mehr mit Administrator privileges!

[PeterPanino]

Hallo und schönen Abend!

Ich habe CodeSite Studio immer problemlos verwendet. Aber seit heute zeigt der CodeSite Live Viewer plötzlich keine CodeSite messages mehr an! (Auch nicht nach einem Neustart des Computers).

Nach einer Weile bin ich dann draufgekommen, dass CodeSite Live Viewer plötzlich nur mehr dann CodeSite messages anzeigt, wenn diese von einem Programm kommen, das im Administrator-Modus gestartet wurde (also im Windows Explorer auf das Programm rechtsklicken -> Run as administrator). Oder die Delphi IDE wird im Administrator Modus gestartet und das Programm dann von der IDE gestartet.

Hat das jemand schon mal erlebt? Was könnte der Grund für dieses Problem sein sein?

[Uwe Raabe]

Kannst du mal prüfen, ob kürzlich irgendwelche Windows-Updates installiert wurden. In einem anderen Fall konnte plötzlich auch von heute auf morgen eine Anwendung keine TCP/IP Verbindung mehr herstellen, ohne das etwas an den Einstellungen geändert wurde (zumindest nicht bewusst).

[PeterPanino]

Systemsteuerung->Programme->Programme und Funktionen->Installierte Updates:

Anhang 49555

Aber seit letzter Woche habe ich CodeSite oft benutzt, und da hat es noch funktioniert.

Kann man nicht einstellen, dass die messages mit Windowsmessages gesendet werden statt mit TCIP/IP?

[Uwe Raabe]

Kannst du das KB2952664 mal raus kicken? Das hat schon häufiger Probleme verursacht.

Zitat:

Zitat von PeterPanino (Beitrag 1408147)

Kann man nicht einstellen, dass die messages mit Windowsmessages gesendet werden statt mit TCIP/IP?

Als Alternative kannst du

Delphi-Quellcode:

CodeSite.ConnectUsingCopyData

aufrufen.

[PeterPanino]

Ich habe jetzt KB2952664 deinstalliert und danach den Computer neu gestartet. Hat leider nichts gebracht.

Jetzt habe ich CodeSite.ConnectUsingCopyData(); gleich an den Anfang von FormCreate gesetzt: Funktioniert leider immer noch nicht.

Im Task manager nachgeschaut: CSDispatcher.exe ist vorhanden, wird aber in der Tray Area nicht angezeigt. Dann CSDispatcher.exe im Task Manager beendet, und dann im Startmenü mit Administrator-Rechten gestartet. Live Viewer zeigt immer noch keine Messages an.

Dann im Traymenü auf Stop Dispatcher geklickt, was den Dispatcher im Task Manager beendet. Dann mein Programm in der IDE gestartet, was den Dispatcher automatisch neu startete. Also reagiert der Dispatcher auf die CodeSite messages.

Das sind die Dispatcher Settings:

Anhang 49556

Anhang 49557

Anhang 49558

[PeterPanino]

CodeSite Controller Settings:

Anhang 49559

Anhang 49560

Anhang 49561

Anhang 49562

Anhang 49563

[PeterPanino]

Habe jetzt noch versucht:

- Zwischen 32-bit und 64-bit umzuschalten.

- CodeSiteLogging an anderen Stellen in der uses-Klausel.

Funktioniert immer noch nicht. Sieht aus, als ob der Dispatcher den Live Viewer nicht erreicht.

[PeterPanino]

Heureka!

CodeSite Studio 5.3.2 neu installiert: Funktioniert wieder!

Jetzt ist nur die Frage: War etwas bei den CodeSite-Programmdateien kaputt oder hat die Installation eines Komponenten-Packages gestern Abend etwas in der IDE verändert, was den Fehler in CodeSite verursachte?

[PeterPanino]

Fehlanzeige! Das wirkliche Problem hat sich jetzt mit Ray's Hilfe herauskristallisiert:

Wenn ein Programm, welches das erste Mal (in einer Windows Session) CodeSite messages sendet und damit den CSDispatcher startet, mit erhöhten Rechten läuft so wird auch der CSDispatcher mit erhöhten Rechten gestartet. Das blockiert aber jene CodeSite Messages, welche von einem Programm mit normalen USER-Rechten kommen. Deshalb wurden nur jene CodeSite messages im LiveViewer angezeigt, die von einem Programm mit erhöhten Rechten kommen, etwa wenn die IDE im Administrator-Modus gestartet wurde und die IDE dann wiederum ein Programm startet. (Übrigens funktioniert OLE Drag&Drop nicht bei einem Programm, das mit erhöhten Rechten läuft).

Das Ganze passierte deswegen, weil ich einen WinLogon TaskScheduler Task mit erhöhten Rechten erstellt hatte, der meine App ebenso mit erhöhten Rechten startete und diese App dann CodeSite messages sendete, die wiederum den CSDispatcher mit erhöhten Rechten starteten.

Zusammengefasst: Man muss nur darauf achten, dass der CSDispatcher NICHT mit erhöhten Rechten gestartet wird. Das kann man auf verschiedene Arten erreichen. Noch besser wäre es, wenn CodeSite selbst mit internen Maßnahmen dafür sorgen würde.

Auf jeden Fall ist jetzt die Ursache des Problem gefunden und das Problem kann umgangen werden.

[PeterPanino]

Hinzu kommt noch erschwerend der Umstand, dass man von einem Programm mit erhöhten Rechten nicht ein Programm (etwa sich selbst) ohne erhöhte Rechte starten kann, was m.E. ein Konzeptfehler von Windows ist, weil eine solche Möglichkeit keine Sicherheitsaspekte von Windows verletzen würde.

Um von einem Programm mit erhöhten Rechten ein Programm ohne erhöhte Rechte (etwa sich selbst) zu starten, musste ich deshalb in einem anderen Zusammenhang zu einem Trick greifen: Eine Windows-Nachricht an ein bereits laufendes Programm senden, das ohne erhöhte Rechte läuft, worauf dieses das gewünschte Programm ohne erhöhte Rechte startet.

Oder kennt jemand einen Trick, mit dem man das auf eine andere einfachere Weise erreichen könnte?

[KodeZwerg]

Zitat:

Zitat von PeterPanino (Beitrag 1408329)

Oder kennt jemand einen Trick, mit dem man das auf eine andere einfachere Weise erreichen könnte?

Per Commandline Aufruf sollte das möglich sein, hier ein Batch Auszug:

Delphi-Quellcode:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %1"

[PeterPanino]

Zitat:

Zitat von KodeZwerg (Beitrag 1408330)

Per Commandline Aufruf sollte das möglich sein, hier ein Batch Auszug:

Delphi-Quellcode:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %1"

Hallo KodeZwerg,

vielen Dank für deinen genialen Gedanken!

Leider funktioniert es nicht so, wie ich es mir gewünscht habe.

Also, ich habe eine Batch-Datei "test.bat" mit diesem Inhalt erstellt:

Code:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" F:\delphi\_test\StartUnelevatedProgramFromElevatedProgram\Win32\Debug\StartUnelevatedProgramFromElevatedProgram.exe"

Wenn ich diese Batch-Datei doppelklicke, wird wie gewünscht mein Programm gestartet. So weit so gut.

Nun versuche ich mal, das Ganze von meinem elevated Programm aus zu starten:

Delphi-Quellcode:

procedure TForm3.btnRestartNotElevatedClick(Sender: TObject);
begin
  JclShell.ShellExecEx('F:\delphi\_test\StartUnelevatedProgramFromElevatedProgram\Win32\Debug\test.bat');
  Close;
end;

procedure TForm3.FormCreate(Sender: TObject);
begin
  // wer MiTeC nicht hat, einfach einen anderen Code verwenden oder auskommentieren:
  if MiTeC_Routines.IsElevated then
    Self.Caption := 'Elevated'
  else
    Self.Caption := 'NOT Elevated';
end;

Ich starte also meine App mit höheren Rechten: KontextMenü im Windows-Explorer -> "Run as Administrator". Nach dem UAC prompt started dann die App elevated.

Dann klicke ich auf den Button: Das Programm startet die Batch-Datei, schließt sich selbst, und die App wird neu gestartet. Aber leider wieder elevated!

Im Anhang ist der Source-Code:

Anhang 49575

[Uwe Raabe]

Zitat:

Zitat von PeterPanino (Beitrag 1408340)

Das Programm startet die Batch-Datei, schließt sich selbst, und die App wird neu gestartet. Aber leider wieder elevated!

Das ist auch nicht verwunderlich, da AsInvoker ja die Rechte des aktuellen Benutzers verwendet. Der ist aber in dem Moment nun mal Admin.

Zitat:

asInvoker – Run with limited user rights unless specifically elevated or called from an already elevated process

[PeterPanino]

Vielen Dank, Uwe.

Gibt es also keinen Trick, von einem elevated Programm aus sich selbst als nicht-elevated neu zu starten?

[Uwe Raabe]

Zitat:

Zitat von PeterPanino (Beitrag 1408344)

Gibt es also keinen Trick, von einem elevated Programm aus sich selbst als nicht-elevated neu zu starten?

Mir ist zumindest kein offizielles Verfahren bekannt.

In der madCollection gibt es in madKernel aber eine Funktion NewProcessAsUser. Vielleicht kann man damit was erreichen, aber ich kann das gerade nicht ausprobieren.

[KodeZwerg]

Ich nutze den Befehl von oben in meiner Registry, hab da ein "Run without Rights" angelegt, das Gegenstück zu "Run as Admin" sozusagen.

Wenn das Ziel UAC beinhaltet und setzen will, kann sein das es dann generell nicht fruchtet.

Was mir noch einfällt wäre der Befehl RUNAS.
Da müsstest Du eventuell erst Richtlinien selber basteln, testen ob das nötig ist kannst Du so:
Öffne eine Commandline (mit/ohne Rechte sollte egal sein)
Tippe "runas /showtrustlevel" ein und drück Eingabetaste.
Je nachdem was Dir da Angezeigt wird kannst Du nun per "runas /trustlevel" switch etwas mit von Dir bestimmten Rechten ausführen. Auch aus Delphi heraus ohne batch oder der gleichen. Wichtig ist halt das eine Richtlinie existiert.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1408359)

Zitat:

Zitat von PeterPanino (Beitrag 1408344)

Gibt es also keinen Trick, von einem elevated Programm aus sich selbst als nicht-elevated neu zu starten?

Mir ist zumindest kein offizielles Verfahren bekannt.

In der madCollection gibt es in madKernel aber eine Funktion NewProcessAsUser. Vielleicht kann man damit was erreichen, aber ich kann das gerade nicht ausprobieren.

CreateProcessWithLogonW, CreateProcessAsUser
oder selbst SecurityAttribute besorgen und CreateProcess.
Problem dabei ist, dass dort wohl überall ohne das UAC der User mit den vollen angeforderten Rechten gestartet wird.

Eventuell über die Aufgabenplanung versuchen? (dort eintragen, dass der Prozess in aktuelle Zeit + x Sekunden gestartet werden soll)

Ich weiß jetzt nicht welche Rechte das UAC standardmäßig deaktiviert ... eventuell kann man seine eigenen Berechtigungen klonen, jene Berechtigungen entfernen und dann damit den Prozess starten.

[KodeZwerg]

Eine funktionierende Lösung wäre es über den Task Scheduler laufen zu lassen.
Vielleicht mit dem VCL Task Scheduler als Hilfe, ob der das macht was ich meine habe ich selbst noch nicht getestet, aber rein von der Logik her funktioniert es so (mit dem Windows Task Scheduler).