aus Dienst herraus Anwendung starten

[mexx81]

Hallo,

ich bin neu hier, aber in einen anderen Delphi-Forum kein unbeschriebenes Blatt. Da ich aber bzgl. meines Problems hier ein paar nützliche Hinweise entdeckt habe, versuche ich hier mal mein Glück.

Mein Problem in der langen Version(ganz unten): http://www.delphi-forum.de/topic_aus...ten_78491.html

Mein Problem kurz:
Ich habe einen Dienst, der eine Anwendung starten soll. Mit ShellExecute und WinExec geht das nicht. Aber mit CreateProzess konnte ich die Anwendung starten, aber ich sehe keine Oberfläche, weil die Anwendung vom Dienst das SYSTEM als Benutzer erbt, was auch der Grund sein wird, weshalb die beiden anderen Funktionen nicht greifen. In diesen Forum habe ich viel über CreateProzessAsUser und CreateProcessWithLogonW gelesen. Beide Funktionen versprechen Erfolg, jedoch muss bei beiden der Benutzername und das Passwort eingegeben werden. Genau das kenne ich jedoch nicht!

• in Bezug auf die lange Version: Nicht jeder Laptop wurde von uns zur Verfügung gestellt und wenn doch, wir haben das lokale Passwort ändern müssen, weil es bekannt wurde. Somit haben wir zwei verschiedene lokale Adminpasswörter im Einsatz und
  
• unbekannte Passwörter von Laptop, welche nicht von uns kommen.

Die hier im Forum gefunden Theman bzgl. dieser Funktion haben aber aus meiner Sicht den Nachteil, dass ich Benutzername und Passwort kennen muss. Ich müsste also sowas wie CreateProzessAsAktiveUser haben, um einen Prozess zu erzeugen, welcher unter den aktiven Benutzer läuft. Nur wie geht das?

Danke, mexx81

[Bernhard Geyer]

Zitat:

Zitat von mexx81

Die hier im Forum gefunden Theman bzgl. dieser Funktion haben aber aus meiner Sicht den Nachteil, dass ich Benutzername und Passwort kennen muss. Ich müsste also sowas wie CreateProzessAsAktiveUser haben, um einen Prozess zu erzeugen, welcher unter den aktiven Benutzer läuft. Nur wie geht das?

Gar nicht! Wäre eine 1A Sicherheitslücke. Unter Vista doppelt nicht.

[Luckie]

Soll ein Dienst mit dem Benutzer interagieren können, muss es ein interaktiver diesnt sein. Dies wird von Microsft allerdings nicht empfohlen, das dieses Vorgehen eine sicherheitslücke darstellt. Unter Vista hat Microsoft auch die interaktiven Dienste abgeschafft.
Um mit einem dienst zu kommunizieren nimmt man deswegen ein Programm im User-Mode, welches über Mailslots, named Pipes etc, mit dem Dienst kommuniziert.

[Relicted]

verständnisfrage:

warum/wie/weshalb gibt es z.b. bei einigen (antiviren-)programmen einen zusätzlichen prozess welcher als eine art watchdog fungiert? programm wird gekillt - prozess sieht das und startet das ganze neu. wie wird das denn gemacht?

gruß
reli

[Bernhard Geyer]

Wenn der Watchdog unter dem gleichen Konto wie das zu überwachende Programm/Dienst läuft sollte es kein Problem darstellen.
Bzw. bei der Installation des Programms werden entsprechende Konten eingerichtet welche die entsprechenden Rechte haben.

[Relicted]

ah okay... wieder was dazu gelernt..

gruß
reli

[madas]

Zitat:

Zitat von mexx81

Mein Problem kurz:
Ich habe einen Dienst, der eine Anwendung starten soll. Mit ShellExecute und WinExec geht das nicht. Aber mit CreateProzess konnte ich die Anwendung starten, aber ich sehe keine Oberfläche, weil die Anwendung vom Dienst das SYSTEM als Benutzer erbt, was auch der Grund sein wird, weshalb die beiden anderen Funktionen nicht greifen. In diesen Forum habe ich viel über CreateProzessAsUser und CreateProcessWithLogonW gelesen. Beide Funktionen versprechen Erfolg, jedoch muss bei beiden der Benutzername und das Passwort eingegeben werden. Genau das kenne ich jedoch nicht!

Versuchs mal damit (naja das funzt schon, auch unter Vista):

Delphi-Quellcode:

var
  hToken : THandle; 
  si: TStartupInfo; 
  pi: TProcessInformation;

...

  if WTSQueryUserToken(WtsGetActiveConsoleSessionID, hToken) then 
  begin
    FillChar(si, SizeOf(si), 0);
    with si do
    begin
      cb := SizeOf(si);
      dwFlags := STARTF_USESHOWWINDOW;
      wShowWindow := SW_NORMAL;
    end;

    if not CreateProcessAsUser(hToken, PChar(strMonitorPath), nil, nil, nil, False,
                               NORMAL_PRIORITY_CLASS or CREATE_NEW_PROCESS_GROUP,
                               nil, nil, si, pi) then
    begin
      OutCount := 0;
      MessageBox(0,PChar(SysErrorMessage(GetLastError)),'',MB_SERVICE_NOTIFICATION or MB_OK);
    end
    else
    begin
      Self.SendToMonitorPipe('RESETMONITOR' + #0);
      Self.SendToMonitorPipe('SHOWMONITOR' + #0);
      OutCount := 1;
    end;
  end
  else
  begin
    OutCount := 0;
    MessageBox(0,PChar(SysErrorMessage(GetLastError)),'',MB_SERVICE_NOTIFICATION or MB_OK);
  end;
  CloseHandle(hToken);

Units zum Einbinden sind: JwaWtsApi32, JWAWinBase

[Luckie]

http://www.delphi-forum.de/viewtopic...c3a6f3a#473785 :roll:

[mexx81]

Die Lösung von madas werde ich mir wohl mal in Ruhe ansehen müssen. Der Link von Luckie ist mein Beitrag, den ich ganz oben schon verlinkt habe! Da habe ich eine, naja, "Ganz-okay-Lösung" gefunden, die ich zunächst verwenden werde. Vista, Vista, Vista!!! Warum glauben alle nur, dass Vista ein Thema ist. Ich bin Admin einer Firmengruppe und sowohl meine Kollegen, als auch die Admins anderen Firmen sagen alle definitiv: Kein Vista vor 2009, wenn überhaupt! Für Firman hat Vista absolut keine Vorteile, nicht einen!!!! Nur Nachteile!!!! Vista kann nichts, was XP nicht auch schon kann. Alle andere zusätzlichen Funktionen von Vista sind für Firmen völlig unrelevant und fressen nur Performance.

[Bernhard Geyer]

Zitat:

Zitat von mexx81

Warum glauben alle nur, dass Vista ein Thema ist.

Wer sagt denn das nicht u.U. im Untergrund einige Vista-Sicherheitserweiterungen auch im XP SP3 Einzug halten? Hier Vista zu ignorieren ist fahrlässig. Übrigens unser Admin hat die letzten neuen PC auch wieder mit XP ausgestatet.

[Phoenix]

Im anderen Forum regst Du Dich darüber auf, dass andere Entwickler ihre Anwendungen nicht Vista-Kompatibel machen.

Zitat:

Wir haben zahlreiche Programme auf den Laptops laufen, welche unter Vista nicht gehen.

Genau aus diesem Grund sollten wir alle darauf achten, dass unsere Programme unter allen Systemen laufen.

Sonst schimpft nämlich auch in Zukunft jeder über das Betriebssystem. Und das, obwohl gerade solche Ignoranten alá "unter XP läuft das doch" oder auch alá "Warum glauben alle nur, dass Vista ein Thema ist." ausschliesslich alleine daran schuld sind, dass die Anwendungen da nicht drauf laufen - und eben nicht das Betriebssystem oder dessen Hersteller die Schuld trägt. :wall:

[Luckie]

Genau das ist das Problem: Hätten sich die Entwickler an die Richtlinien gehalten, die es übrigens schon seit NT gibt, dann gäbe e so gut wie keine Probleme mit Vista. Da aber genau aus diesem Grund die meisten unter XP als Administrator arbeiten, merken sie nicht, wie schelocht die Software programmiert ist, mit der sie arbeiten.

[Relicted]

*zustimm*

daher: mut zu vista!
ich selber nutze sogar das ganz ganz böse vista... Vista 64 Business..
also falls jemand seine programme unter [ironie] nieeeeeeeemals sich etablierenden/benutztbaren [/ironie] systemen testen mag: immer her mit der exe :-)

ich erinnere mich noch dunkel... es ist nicht so lange her aber man verdrängt es gerne... ich erinnere mich an aussagen *inversiv glaskugel hervorhol* "boah scheisse was soll das für ein OS sein?! XP?? pah! ich bleib auf 98.. da läuft wenigstens alles und super stabil!!" oder wie wärs mit dem hier: "für das neue xp entwickeln? quatsch.. zu viel aufwand für ein OS was nieeeee!! nieeee! produktiv in firmen zum einsatz kommen wird!!"


gruß
reli

[Dezipaitor]

Delphi-Quellcode:

if WTSQueryUserToken(WtsGetActiveConsoleSessionID, hToken) then

Das Problem mit dieser Zeile ist, dass immer die physikalische Konsole verwendet wird. D.h. wenn kein Benutzer lokal eingeloggt ist, dann schlägt die Funktion fehl. Dies kann z.b. passieren wenn jemand über RemoteDesktop eingeloggt ist (ohne den Desktop als ConsoleSession zu starten).
Auf jeden Fall kann die gestartete Anwendung auf dem falschen Desktop gestartet werden.

Am einfachsten kann man dieses Problem lösen, wenn der Benutzer eine Aktion auslöst, die diese Anwendung startet. D.h. eine Anwendung kommuniziert mit dem Service, der dann einen neuen Prozess startet. Durch die Kommunikation kann der Service erfahren, in welche Session und Desktop die Anwendung steht und dort den neuen Prozess starten.

[madas]

Zitat:

Zitat von Dezipaitor

Delphi-Quellcode:

if WTSQueryUserToken(WtsGetActiveConsoleSessionID, hToken) then

Das Problem mit dieser Zeile ist, dass immer die physikalische Konsole verwendet wird. D.h. wenn kein Benutzer lokal eingeloggt ist, dann schlägt die Funktion fehl. Dies kann z.b. passieren wenn jemand über RemoteDesktop eingeloggt ist (ohne den Desktop als ConsoleSession zu starten).
Auf jeden Fall kann die gestartete Anwendung auf dem falschen Desktop gestartet werden.

Am einfachsten kann man dieses Problem lösen, wenn der Benutzer eine Aktion auslöst, die diese Anwendung startet. D.h. eine Anwendung kommuniziert mit dem Service, der dann einen neuen Prozess startet. Durch die Kommunikation kann der Service erfahren, in welche Session und Desktop die Anwendung steht und dort den neuen Prozess starten.

Also ich verwende das für einen Update Service. Die Anwendung fragt dann den Service, ob ob ein Update machbar ist oder nicht. Um dem User Infos zum Updatevorgang zu zeigen, gibt es einen Update Monitor. Falls er nicht läuft wird er vom Service im Userkontext gestartet.

Klingt doch eigentlich nach deiner "Problemlösung", oder?

Ich frage deshalb nochmal, weil auf gleiche Weise dann auch wieder die Anwendung selber nach einen Update gestartet wird. Sie muss ja auch wieder im User Kontext laufen.