Windows-Dienst, Notification, Zugriff verweigert

[Delrabe]

Hallo,

auf einem Windows 10-Rechner verwalte ich ein komplexes und umfangreiches Delphi-Projekt mit Datenbank-Anbindung und einem funktionierenden Update-Mechanismus. Zusätzlich hätte ich gerne einen Windows-Dienst, der bei Anwendern gelegentlich prüft, ob Programm-Updates vorhanden sind, und dies ggf. meldet. Dies ist in erster Linie gedacht für Sys-Admin's, die Software auf Client-Rechnern verwalten, und für sporadische User, die gerne einmal ein Update verpassen.

Inzwischen habe ich den Dienst (TService-Anwendung) und einen Dienst-Monitor (Standard-Anwendung) erstellt. Mit dem Dienst-Monitor kann man Dienst-Details einstellen und die Standard-Aktionen (Dienst installieren, starten usw.) vornehmen. Alles funktioniert wie gewünscht, nur kann der Dienst derzeitig keine Meldung an den User schicken.

Dies hatte ich natürlich als erstes geprüft, und das war via TNotificationCenter, TNotification und PresentNotification sehr einfach. In einer normalen Anwendung funktioniert das auch ohne Probleme, nur beim Dienst erfolgt immer die Meldung "Zugriff verweigert".

Inzwischen habe ich zusätzlich eine kleine Anwendung erstellt, die unsichtbar das Melden übernimmt und die Aktionen protokolliert. Dieses Notify-Programm ruft man auf und übergibt dabei die Meldungsdaten als Parameter. Es ergibt sich dabei dasselbe Verhalten. Beim Aufruf aus einer "normalen" Anwendung funktioniert die Sache, beim Aufruf aus dem Dienst heraus wird bei "NotificationCenter.PresentNotification" wieder der "Zugriff verweigert".

Ich habe mir inzwischen schon den Wolf gegoogelt nach möglicherweise fehlenden Rechten sowie Besonderheiten bei Notification und Windows-Diensten, habe aber nichts gefunden. Ich hoffe, dass mir jemand helfen kann.

[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.