Who Runs the Service?

A key component of the Win32 security model in Windows 2000 is that every process runs under the authority of some user. This is required so that upon each request to the operating system, the security on the object that is being requested can be tested against the rights of the current user or the groups the current user belongs to. If this is how security is handled, how do services run when no one is logged on?

The answer is a little more complicated than it might seem. Generally, the service runs in the context of the System account, a special account that has godlike powers on the machine that houses the account but cannot cross the wire and access resources on any other machine. It is obvious from that description that running under the System account is not always a perfect solution, since sometimes your service might want to cross the wire and gain access to resources on another machine. For instance, a service that does file backups might want to back up files on remote servers if the tape drive hardware exists on only one of several machines requiring backups .

NOTE

---

While testing some of the programs in this chapter, I discovered that the System account has no power beyond the machine it resides on. As a matter of course, I was compiling some of the service applications on the server. Installing them from the directory where they were created on the server was not a problem. Actually starting the service was a problem. In retrospect, it is clear why: the System account could not access the executable on the remote server. In general, of course, no serviceeven one that is running under a properly authorized accountshould be run from a server. With most automatically started services, it would be difficult to reliably ensure that the service application residing on the server will be available when the service tries to start.

The solution to this problem is the ability to run a service within the context of a user account rather than the context of the System account. This can be accomplished programmatically as well as through the user interface. Figure 3-1 shows the property sheet for a service, which you can use to set the user name and password for the user account a service should run under.

Figure 3-1 Setting the user context for a service in Windows 2000.

Services are managed by the Service Control Manager (SCM). The SCM maintains a database of services, controls their installation, and starts them up at boot time or upon demand. Many operations on services require the handle of the SCM, and the SCM of remote machines can also be opened on the machine where the request for the handle takes place.