Service -> in eine Konsole schreiben

[Meflin]

Aloha!

Ich habe eine Service Anwendung. Von der aus möchte ich nun die Konsole starten, und Nachrichten reinschreiben (praktisch als Verbose Output). Das sollte doch mit einem interaktiven Service möglich sein oder?

Allein... wie?

[faux]

Du musst einfach den Service mit ausreichenden Rechten ausführen, bzw. dem Service erlauben, dass es "auf den Desktop zugreift" (so heißt die Einstellung).
Das musst du aber bei der Installation des Services vornehmen, da das Windows-Einstellungen sind.

Grüße
Faux

[Olli]

Zitat:

Zitat von faux

Du musst einfach den Service mit ausreichenden Rechten ausführen, bzw. dem Service erlauben, dass es "auf den Desktop zugreift" (so heißt die Einstellung).
Das musst du aber bei der Installation des Services vornehmen, da das Windows-Einstellungen sind.

Aua, nein nein nein! :lol:

Endlich hat es MS geschafft, die Leute zu überzeugen, daß interaktive Dienste böse sind (wegen Shatter Attack Interactive Service), da kommt jemand aus der DP und empfiehlt diese Technik :shock:

Der korrekte Weg ist es, sich über die ACLs des Desktops und der interaktiven Fensterstation Zugriff zu verschaffen und maximal interaktive Elemente in einem eingeschränkten Kontext ([msdn]Client Impersonation [Security][/msdn]) laufen zu lassen.

[Meflin]

Zitat:

Zitat von Olli

Der korrekte Weg ist es, sich über die ACLs des Desktops und der interaktiven Fensterstation Zugriff zu verschaffen und maximal interaktive Elemente in einem eingeschränkten Kontext ([msdn]Client Impersonation [Security][/msdn]) laufen zu lassen.

Huch... ich verstehe nur Bahnhof :stupid: könntest du deine Ausführungen etwas präzisieren?

[faux]

Zitat:

Zitat von Olli

da kommt jemand aus der DP und empfiehlt diese Technik :shock:

Hmpf... Ich hab weder meine Meinung dazu gesagt, noch im das Empfohlen noch gesgat, dass das eine gute oder schlechte Methode ist... :roll:
Immer auf die Kleinen... :mrgreen:

[Olli]

Zitat:

Zitat von Meflin

Huch... ich verstehe nur Bahnhof :stupid: könntest du deine Ausführungen etwas präzisieren?

Das überlasse ich mal dem PSDK:

Zitat:

Each service has an associated window station and desktop. Only one window station, Winsta0 can be an interactive. Any desktops created on the interactive window station can display objects to the user and receive user input. Other desktops cannot display objects or receive user input. Processes started by the logged-on user are associated with the default desktop in the Winsta0 window station (Winsta0\default).


The particular window station and desktop combination used by a service is determined by the account in which the service is running. If the service is running in the security context of the LocalSystem account and does not include the SERVICE_INTERACTIVE_PROCESS attribute, it uses the following window station and desktop: Service-0x0-3e7$\default. This window station is not interactive, so the service cannot display a user interface. In addition, processes created by the service cannot display a user interface.

If the service is running in the security context of a user account, the name of the window station is based on the user SID: Service-0xZ1-Z2$, where Z1 is the high part of the logon SID and Z2 is the low part of the logon SID. Because a SID is unique to the logon session, two services running in the same security context receive unique window stations.

If the service is running in the context of the LocalSystem account and has the SERVICE_INTERACTIVE_PROCESS attribute, it is known as an interactive service. It can display a user interface and receive user input. Refer to the Security Considerations for Interactive Services section below for important information on how to ensure that your interactive service sessions are secure.

To determine whether a service is running as an interactive service, call the GetProcessWindowStation function to retrieve a handle to the window station, and the GetUserObjectInformation function to test whether the window station has the WSF_VISIBLE attribute.

However, note that the following registry key contains a value, NoInteractiveServices, that controls the effect of SERVICE_INTERACTIVE_PROCESS:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Windows


The NoInteractiveServices value defaults to zero, which means that services with SERVICE_INTERACTIVE_PROCESS are allowed to run interactively. When NoInteractiveServices is set to a nonzero value, no service started thereafter is allowed to run interactively, regardless of whether it has SERVICE_INTERACTIVE_PROCESS.


Security Considerations for Interactive Services

Note that running interactive services under the LocalSystem context is a dangerous practice and should be avoided. If a service that is running on a multiuser system must interact with a user, the service should do so through a separate GUI application running within the context of the user session. This GUI application should be designed to communicate with the service through some method of interprocess communication, such as a named pipe. This is a client/server implementation.

The server process (the interactive service) then communicates with the appropriate client through interprocess communication to tell the client when to display the GUI. The client then communicates the results of the user interaction back to the service so that the service can take the appropriate actions. By using named pipes, the server can distinguish between multiple user processes by giving each pipe a unique name.


Interacting with the User from a Noninteractive Service

It is possible to display a message box from a service, even if it is not running in the LocalSystem account or not configured to run interactively. Simply call the MessageBox function using MB_SERVICE_NOTIFICATION. Do not call MessageBox during service initialization or from the HandlerEx routine, unless you call it from a separate thread, so that you return to the SCM in a timely manner.

It is also possible to interact with the desktop from a non-interactive service by modifying the DACLs on the window station and desktop, or by impersonating the logged-on user and opening the interactive window station and desktop directly. This allows services to provide a user interface, while maintaining the security of applications running in the account of the logged-on user. For more information, see Interacting with the User in a Service.

Quelle: Interactive Services

[Meflin]

Also ich hab das jetzt folgendermaßen gelöst:

Ich weise dem Service mit

Delphi-Quellcode:

AllocConsole

eine Konsole zu. In die kann ich dann via

Delphi-Quellcode:

writeln

Sachen schreiben. Das funktioniert auch bestens. Allerdings:

1. Wenn man die Konsole beendet, endet auch der Service. Warum ist dem so?

2. Ist das eine saubere / akzeptable Lösung?

[Olli]

Was ist denn dein Ziel? Beschreibe mal nicht wie du es machen willst, sondern was dein Ziel ist ;)

[Meflin]

Zitat:

Zitat von Olli

Was ist denn dein Ziel? Beschreibe mal nicht wie du es machen willst, sondern was dein Ziel ist ;)

Ganz einfach: ich entwickle einen Service, und damit das testen des Services einfacher ist, will ich irgendwie ausgeben, was er gerade tut bzw nicht tut oder was warum fehlgeschlagen ist. Das schreibe ich eben in eine Konsole, damit es der Tester lesen kann. Wenn der Service fertig entwickelt ist, wird diese Konsole wieder aus dem Programm rausgenommen, stört den User ja nur...

[Olli]

Wie wäre es dann, wenn du dir der Einfachheit halber DebugView besorgst und in deiner boot.ini die DEBUG-Option aktivierst, so daß du die API-Funktion OutputDebugString benutzen kannst? So kannst du live deinen Service beobachten, ohne hier Kopfstände machen zu müssen.