Windows Service, Process.Start

  • Thread starter Thread starter SR
  • Start date Start date
S

SR

I have a requirement from a customer to run some command line applications
from a service. I have most of my service coded and I've come across an
issue with the important part of the application, naturally.

When my service tries to start the command line application, I get an Access
is Denied error unless I set UseShellExecute to false; in which case the
external command line application does not execute.

The structure of my application is that when a file is found that needs
processing by the command line application, a function from a class
inherited from the ConfigurationSection (there is a reason for this, I can
explain if relevant) is called. This function runs the following code:

oProcess = New Process
oProcess.StartInfo.FileName = oCommand.Application
oProcess.StartInfo.Arguments = oCommand.Arguments & " " & """" & FileName &
"""" & " " & """" & sOutFile & """"
oProcess.StartInfo.CreateNoWindow = True
oProcess.StartInfo.UseShellExecute = False
oProcess.Start()
oProcess.WaitForExit()
If Not oProcess.HasExited Then
oProcess.Kill()
End If

I am running the service as LOCALSYSTEM and I am not assigning a user to the
process...what user is assigned to the process if I do not assign one?
Maybe that is the issue?

Any insight into this problem would be great! TIA

Seth
 
Any process spawned from a service will run under the same account that the
service is running under.

In this case, you need to give the LocalSystem account, at least the
following permissions:

execute permission on the executable defined by oCommand.Application

read permission on files in the directory defined by FileName

create and write permissions on files in the directory defined by sOutFile

any other permissions required to access resources used by the executable
defined by oCommand.Application (whatever thay may be)

As an alternatively tou could run the service under an account that already
has ALL the necessary permissions.
 
Thanks.

Unless I am incorrect, the LocalSystem account is actually SYSTEM in the
users. SYSTEM has all of those privledges already.

It seems I will have to run it as a local user account...
 
Back
Top