Can I run a service executable from a network location?

A customer liaison wanted to know whether it is possible to run a service executable from a network location. The customer was doing so and running into problems, and they wanted to know whether it is a legal scenario.

Running a service from a network location is a bad idea. If the computer lose network connectivity momentarily, the service may die with STATUS_IN_PAGE_ERROR. (You can try to mitigiate this with /SWAPRUN:NET.) Plus there is a security issue here, because your computer is now trusting code that is coming from another computer. If somebody attacks your network and masquerades as the other computer, they can inject code into your computer with system privileges. If that other computer becomes compromised, then the attacker can inject code onto any computer that is running a service from the compromised computer.

But even though it's a bad idea, it is nevertheless technically legal, in the same way that it is technically legal to use strcpy or to park your car and leave the windows open and the key on the front seat.

But if you run into problems, all everybody is going to tell you is, "Don't do that."

(The MSDN documentation advises against putting the service executable on another computer, which is already a step up from the traditional MSDN approach of merely providing facts and leaving you to develop your own guidance. But it can't bring itself to say that doing so is a bad idea; it merely says that "It is best to use a local file.")

Comments (10)
  1. Joshua says:

    You're running domain-joined Windows. You can be taken over across the network. The only block I can find is to completely diasblr group policy that it can't put Domain Administrators back in the Administrators group.

  2. ShuggyCoUk says:

    Given that it is now common to boot the machine from a network location I find it somewhat surprising that running a service from one is a worry so long as you can lock down the location…

    Now the issues of delay loading and network drops/file removals is a whole other concern.

  3. Kevin says:

    I love it when documentation expresses an opinion.  It's usually a sign that things are pretty messed up.  E.g. this line from fcntl(2):

    As well as being removed by an explicit F_UNLCK, record locks are automatically released when the process terminates or if it closes any file descriptor referring to a file on which locks are held. This is bad: it means that a process can lose the locks on a file like /etc/passwd or /etc/mtab when for some reason a library function decides to open, read and close it.

  4. Joshua says:

    @Kevin: Don't use fcntl() except for its intended purpose: a mutli-process database. The files you name have other lock protocols.

  5. Joshua says:

    You're right there's no portable way to avoid that gotcha. There is no strict file locking on Unix platforms and that's the point. If you're going to be using file locking, everybody has to be in on the game.

  6. Gabe says:

    Joshua: The problem is that it's impossible to get everybody in on the game. Let's say you're writing a POSIX version of Access — a fancy GUI DBMS — so obviously you'll be using file locking to control access to the DB across different users.

    Now let's say that the user goes to open a file, and the Open File dialog that is part of the GUI toolkit wants to show icons for all the files in a directory. It may open every file, like file(1) does, to figure out its type so it can show the proper icon for the file.

    Well, if it happens to open your current database to find out its type, it will eliminate any locks currently held.

  7. Kevin says:


    On Linux (with glibc), lockf(3) is implemented in terms of fcntl(2) and has the same problems.  On some systems (including very old Linuxes), flock(2) doesn't exist and is also emulated via fcntl(2) (or it just plain doesn't compile, YMMV).  In short, there is no portable way to avoid that gotcha under POSIX systems.

    Besides, fcntl(2) doesn't *have* an intended purpose.  It does *everything*.

  8. Dave Bacher says:

    Realistically, if a Windows server can masquerade as another Windows server, you have worse problems than a service executable.

    I'd also be more concerned about paging in from the wrong executable (e.g. someone updates the copy on the server) — than a segment violation.  A segment violation is clearly identifiable.  Loading the wrong code page, that could go unnoticed for an extended period of time and corrupt data.  Meanwhile, server side, just two clicks to clear the lock.  "Oh, stupid Windows, won't let me change this exe file, I'll show Microsoft, click click, there now I can update it."

  9. cheong00 says:

    @ShuggyCoUk: If your scenario involves "boot from network location", why can't you just update the service file located inside boot image?

    As for why you should worry, see more information by searching for "ARP Spoofing". When your ARP cache is poisoned, your "locked down location" is not locked.

  10. anonymouscommenter says:

    @cheong00: As for why you should worry, see more information by searching for "ARP Spoofing". When your ARP cache is poisoned, your "locked down location" is not locked.

    That's why you don't boot from a hostile network. Only local where no hostile physical access is guaranteed.

Comments are closed.

Skip to main content