Windows-Dienst, Notification, Zugriff verweigert

[himitsu]

Das hat nichts mit Notifications zu tun.

Interactive Dienste sind seit Jahrzehnten grundsätzlich verboten.
Ebenso ist der Zugriff aus einer anderen Session/Desktop nicht erlaubt. (ist im Printip das Gleiche)

Interaktiv = mit dem Nutzer reden/interagieren


Rate mal, warum viele andere Anwendungen auch eine extra NotifyApp im aktuellen Nutzerkontext starten, oder beschissener Weise dauerhaft nutzlos mitlaufen lassen?
CreateProcessAsUser
CreateProcessWithLogonW
CreateProcessWithTokenW
usw.


Man kann zwar via Impersonation auch den eigenen Prozess einen Thread des eigenen Prozesses in einen anderen Kontext verschieben, aber das hilft nicht bei Allem und hat sowieso einige Nachteile.




OpenInputDesktop
WTSGetActiveConsoleSessionId
via WMI abfragen welcher Nutzer im aktiven Desktop in der aktiven Konsole eingeloggt ist. (nicht Konsole wie Konsole aka CMD, sondern wie Konsole aka Monitor+Tastatur/Maus)
oder sonstwas


[add]
https://stackoverflow.com/questions/...t-user-session
https://www.delphipraxis.net/101151-...-tservice.html

[Delrabe]

Hallo himitsu,

vielen Dank für die schnelle Antwort. Damit weiß ich jetzt, wo genau der Schuh drückt und wie man das Problem prinzipiell beheben kann.

Eine Notify-App habe ich ja schon benutzt; es geht jetzt wohl darum, diese richtig aufzurufen. Leider hat der erste Versucht mittels "SvcLaunchAppInCurrUserSession" aus
https://stackoverflow.com/questions/...t-user-session
auch nicht funktioniert. Das muß ich erst noch analysieren und ggf. Alternativen ausprobieren.

Ich melde mich, sobald ich ein Ergebnis habe.

[Sinspin]

Du brauchst eine Kommunikation zwischen den beiden Programmen die über Sessions (virtuelle Desktops) hinweg funktioniert. Dafür hat Windows Schnittstellen geschaffen die man verwenden muss.
Wir verwenden zur Kommunikation eine NamedPipe.
Der Service ist der PipeServer und muss der Pipe das Recht (eine Custom Security Description) geben, mit anderen Programmen außerhalb der eigenen Session reden zu können.

[Delrabe]

Hallo,

kurzer Zwischenbericht: Offenbar geht es darum, das Notify-Programm aus dem Dienst heraus in geeigneter Weise aufzurufen. Dafür habe ich anhand der Beispiele im Netz eine Variante von "ExecuteAsUser" entwickelt. Damit verschwindet bei dem Notify-Aufruf das frühere "Zugriff verweigert". Leider wird jetzt beim Aufruf von "CreateProcessAsUser" der Fehler "Der angeforderte Vorgang erfordert erhöhte Rechte" gemeldet. Die betreffenden Prozeduren befinden sich alle in der beiligenden Unit. Der kritische Punkt ist vielleicht "TExecUsrRec.CrtFlags". Damit habe ich nicht viel Erfahrung. Möglicherweise muß man auch noch etwas beim TStartupInfo einstellen.

Zusatz-Info: Insgesamt sind 3 Delphi-Programme beteiligt; die Dienst-Anwendung, das Monitor-Programm und die kleine Notify-App. Bei den ersten beiden verlange ich Admin-Rechte, bei der Notify-App ist das wohl nicht nötig. Ich weiß aber auch nicht, über welche Rechte der Dienst verfügt, wenn er über "Dienst.exe /Install" aus dem Monitor-Programm erstellt wird.

[peterbelow]

Zitat von Delrabe:

Ich weiß aber auch nicht, über welche Rechte der Dienst verfügt, wenn er über "Dienst.exe /Install" aus dem Monitor-Programm erstellt wird.

Per default läuft ein Service unter dem System-Account, man kann ihm aber über das Service-Applet auch einen anderen Account zuordnen.

[Delrabe]

Hallo,

@Sinspin: Danke für den Hinweis, die Kommunikation zwischen dem Dienst und der Notify.App ist in meinen Augen kein Problem. Die Daten könnten z.B. in einer Datei vom ini-Typ stehen, wo der Dienst unter [MELDUNG] die gewünschten Meldungs-Daten einträgt und die Notify.App anschließend unter [NOTIFY] das Ergebnis und ggf. die Fehlermeldung einträgt. Der Dienst könnte bei Bedarf eine solche Datei erstellen und beim Aufruf der Notify.App diese Datei als Parameter übergeben.

Das Problem ist aber genau dieser Aufruf der Notify.App aus dem Dienst heraus. Das ist offenbar direkt nicht gestattet, weshalb wohl ein Aufruf als "aktueller User" bereitgestellt wird. Leider funktioniert der derzeitig nicht.

Im Detail: Ich verschaffe mir das "Token" des aktuellen Users, wobei "WtsGetActiveConsoleSessionID" und "WTSQueryUserToken" verwendet werden, und rufe danach "CreateProcessAsUser" mit den entsprechenden Parametern auf (vgl. den Quellcode). Leider bekomme ich jetzt eine Fehlermeldung, die wohl bedeutet, dass Admin-Rechte fehlen. Das verstehe ich nicht. Für den Aufruf der Notify.App sind eigentlich keine Admin-Rechte notwendig. Ich selbst bin als Admin angemeldet, nicht als Sys-Admin, aber was spielt das für eine Rolle? Hier wäre ich dankbar für Erläuterungen.

Inzwischen habe ich eine Variante mit "TImpersonateUser" aus dem Netz eingebaut, die wahlweise benutzt werden kann (vgl. die neue Version des Quellcodes). Die funktioniert aber auch nicht, Meldung "Eine Anmeldeanforderung enthielt einen unzulässigen Wert für den Anmeldungstyp" (ERROR_INVALID_LOGON_TYPE). Das liegt möglicherweise daran, dass man zwar den aktuellen User bestimmen kann, aber man kennt natürlich nicht sein PW. Mein Verdacht ist, dass diese Möglichkeit für spezielle Fälle benutzt wird, wo man in einem Programm ein PW abfragt, um Zugriff auf spezielle Features zu ermöglichen.

@peterbelow: Danke für den Hinweis.

@Sinspin: Bei den "Windows Schnittstellen", die man verwenden sollte, wäre ich dankbar für ein paar zusätzliche Info's. So kann ich damit nichts anfangen.

[QuickAndDirty]

Ich mag das Problem total falsch verstehen,
aber spricht irgendetwas gegen ein Programm das in der Systemtray mit läuft und sich im Autostart in der registry einrichtet und dann den Dienst überwacht und von dem Dienst auch mitgeteilt bekommt, wenn es mal ne Meldung Anzeigen soll?
Ist das nicht mehr "state of the art"?