Executing Commands From Windows Service

[T]

On Feb 9, 4:25 pm, David Bolen <db3l.... at gmail.com> wrote:
> David Bolen <db3l.... at gmail.com> writes:
> > Not from my past experience - the system account (LocalSystem for
> > services) can be surprising, in that it's pretty much unlimited access
> > to all local resources, but severely limited in a handful of cases,
> > one of which is any attempt to access the network.  I can't recall for
> > sure if it's an absolute block, or if in some cases you can configure
> > around it (e.g., it might use a null session for remote shares which
> > can be enabled through the registry on the target machine).  I've
> > basically stuck "LocalSystem = no network" in my head from past
> > experience.
>
> Given it's been a few years, I decided to try some tests, and the
> above is too simplistic.
>
> The LocalSystem account runs without any local Windows credentials
> (e.g., not like a logged in user), which has several consequences.
> One is that you can't access any network resources that require such
> credentials (like shares).  However, there's no sort of firewall
> filtering or anything, so plain old TCP/IP connections are fine.
> Unless, of course, the client being used also has other needs for
> local Windows credentials, independent or as a pre-requisite to the
> network operations.
>
> So backing up a bit, the TCP/IP connection that plink is making is not
> inherently disabled by running under LocalSystem, but it's certainly
> possible that plink is trying to identify the user under which it is
> operating to perhaps identify ssh keys or other local resources it
> needs to operate.  You might be able to cover this with command line
> options (e.g., plink supports "-i" to specify a key file to use), but
> you'll also need to ensure that the file you are referencing is
> readable by the LocalSystem account.
>
> One of the other responders had a very good point about locating plink
> in the first place too.  Services run beneath an environment that is
> inherited from the service control manager process, and won't include
> various settings that are applied to your user when logged in,
> especially things like local path changes, and working directories.
> Should you change the system path (via the environment settings),
> you'll need to reboot for the service control manager to notice - I
> don't think you can restart it without a reboot.
>
> So it's generally safer to be very clear, and absolute when possible,
> in a service for paths to external resources.
>
> The prior advice of running the service as an identified user (e.g.,
> with local credentials) is still good as it does remove most of these
> issues since if you can run the script manually under that user you
> know it'll work under service.  But it's not a hard requirement.
>
> If your script is dying such that a top level exception is being
> raised you should be able to find it in the application event log.  So
> that might give further information on what about the different
> environment is problematic.
>
> You can also use the win32traceutil module to help with grabbing debug
> output on the fly.  Import the module in your service, which will
> implicitly redirect stdout/stderr to a trace buffer.  Run the same
> win32traceutil module from the command line in another window.  Then
> start the service.  Any stdout/stderr will be reflected in the other
> window.  Can't catch everything (suppressed exceptions, or I/O that
> doesn't flow through the script's stdout/stderr), but again might help
> point in the right direction.
>
> -- David

Great suggestions once again - I did verify that it was at least
running the plink.exe binary when under LocalSystem by having the
service run "plink.exe > C:\plinkoutput.txt" - this worked fine.  And,
as I mentioned, it's now working just fine when running under a
regular admin account.  So, I think that's going to be my solution to
avoid any further issues.  My best guess at this point (as you
mentioned), is that plink.exe is doing _something_ network-related
that LocalSystem doesn't have the privileges to do - what exactly it
is, I have no idea.  I may play around with it some more later, but
running the service under an admin account should be a perfectly
acceptable solution.

Also, I will be writing other Python apps that the service will be
executing - so it goes without saying that I'll be including a log to
file option :)  Thanks again for all your guys' help!