Starting a Interactive Process in Vista using TService

[Dezipaitor]

You can start gui from a service. You need to use the logon credentials of the user not the service. You cannot create a window for the user display using session 0 - however you could create window for session 0, but it would not be accessible. Actually Vista do show such a window on a new desktop, but this could change on next update.

This example shows how to start cmd.exe from a service using the user credentials of the interactive logon session the user logged on. This does not work, if no user is logged on!
To use WTSQueryUserToken you must include Jedi Api Lib or just load it from windows dll. (see MSDN for more information) -
http://jedi-apilib.sourceforge.net

Delphi-Quellcode:

procedure TService1.ServiceExecute(Sender: TService);
var hToken : THandle;
  si: TStartupInfo;
  pi: TProcessInformation;
  bTerminate: Boolean;
  ACurrentDir: String;
begin
  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('cmd.exe'), nil, nil, nil, False,
                               NORMAL_PRIORITY_CLASS or CREATE_NEW_PROCESS_GROUP,
                               nil, nil, si, pi) then
      MessageBox(0,PChar(SysErrorMessage(GetLastError)),'',MB_SERVICE_NOTIFICATION or MB_OK)
  end
  else
   MessageBox(0,PChar(SysErrorMessage(GetLastError)),'',MB_SERVICE_NOTIFICATION or MB_OK);

  CloseHandle(hToken);
end;

[Dezipaitor]

Zitat:

Zitat von Tyrael Y.

You can´t start a GUI application from a service in Vista.

To display GUI from service you must start a non visible application with the service and this application have to start the GUI elements.

If you need data of interaction you have to implement communication between service and non-visible application e.g. TCP.



[Service] <------> [Non-Visible-App] <------> [GUI-App]

1. You can't directly display a gui in a service. Actually Vista displays a service gui in a seperate desktop. This will change and make it useless.
2. You dont need an invisible app
3. MessageBox with MB_SERVICE_NOTIFICATION works as a display.

The correct image is this:

[Service] <---- communication protocol (TCP, Pipe, Shared Memory...) ---> [Gui-App in a seperate process, started by service or user]

[OregonGhost]

While I still cannot imagine a situation where starting an interactive application from a service is necessary, I have three questions to this approach:

1. What happens if more than one user is logged on?
2. Where does the service get the user login password from?
3. What happens if the service does not run with full rights?

Oh, apart from the question what happens if services and user applications are even more separated from each other in the next version of the operating system :mrgreen:

[Apollonius]

@2 and 3:

MSDN about WTSQueryUserToken:

The calling application must be running within the context of the LocalSystem account and have the SE_TCB_NAME privilege

[Dezipaitor]

Zitat:

Zitat von OregonGhost

While I still cannot imagine a situation where starting an interactive application from a service is necessary, I have three questions to this approach:

1. What happens if more than one user is logged on?
2. Where does the service get the user login password from?
3. What happens if the service does not run with full rights?

Oh, apart from the question what happens if services and user applications are even more separated from each other in the next version of the operating system :mrgreen:

1. WtsQueryUserToken with WtsGetActiveConsoleSessionID uses always the lonely console session. The console session is the session which the keyboard and mouse inputs send their data. Its not a terminal session. You can provide other terminal session.
Wts_Functions are only supported in XP and newer.

2. There is no need. A token is a passport of the user. A service has the power to obtain a copy of it and use it for whatever it wants. LogonUser is only necessary if you want to use user credentials for a user who is not logged on.

3. WtsQueryUserToken needs the TCB privilege to be hold by the process. If the service is started with other credentials the function simply fails and none of this will work.

4. How could that be possible? Communication is always needed. Otherwise we could not communicate with hardware which is necceesarry. However the next step is to seperate secure and unsecure apps.

[OregonGhost]

@4.: What I meant was direct communication between a service and an interactive application. Some time ago, services lost the ability to directly manipulate windows on interactive desktops (should be since XP, if the service was configured appropriately), but I consider starting an interactive application in a user context basically the same and won't be surprised if that can't be done anymore in the future. Indirect communication like TCP/IP or pipes should always be available, but in my opinion a service should not be able to start or manipulate a user application. If the service needs to communicate with the user, maybe it should not have been a service in the first place. But as repeatedly said, that's just my opinion on consequently restricting access and I'm just curious and like to hear why it should stay the way it is.

[Dezipaitor]

You mean by direct communication : SendMessage ?
TCP, Pipe is also direct communication.

The only real direct communication is that code calls functions in the same process. And that does not work with GUI, too.

[OregonGhost]

TCP/IP and Pipes are rather indirect communication methods in the context I described above, as the other side has to expect and accept the connection and must explicitly read the data. SendMessage and PostMessage (and all these nice input emulation functions) usually force an action in the application, as most applications delegate most window messages to the default window procedure and there should never be a need for a service to control a GUI application like that. And if just showing a window falls into that category, starting an application which shows a window should fall into the same category.
However, as in a correctly configured environment any application should be properly installed by an administrator and write-protected for an interactive user, there shouldn't be as much of a problem as I initially thought. I'm just thinking that the service can never know if the application is the one it seems to be or not, maybe I'm a little paranoid in these things. Read too much about threat modelling in the last weeks, I guess :mrgreen:

[Dezipaitor]

Okay thats correct.

However in a good env. a user should also install an application without consultion an admin. Applications which want admin rights do really need a good reason for that - imho.
I hate apps which always want admin rights - i do not install them at all.

A service and its client app is truly a team. Any client app can send messages to the service. However the service must always check the input.
The client app can be signed with a reliable certificate which can be checked by the service. To create such a certifcate is simple but expensive. Reliable organisations want money for that.

[OregonGhost]

Yes, that's basically true. But as you wrote, the GUI application that is part of a service either must not be writable by the user (which is OK in this case, as you need admin rights to install the service anyway), or the service has to prove that the application is the correct one.

Hopefully this talk doesn't go too far away from the original author's question, though it gets a little off-topic :mrgreen: