Take the 2-minute tour ×

I'm writing a small services which will store files on disk and later, on request, return them to the client.

I'm looking over my options when it comes to securing this service so no unauthorized program can read/write the data.

The simplest solution would use impersonation so that the service thread handling the call impersonate the client and have the file system sort out what can be done or not.

The problem here is that the service itself has to be able to read the files without the impersonation (periodical functions running in the background).

I do have read the following chapter on MSDN, I'm looking for practical tips that you or other have used in the past to secure such service.


share|improve this question

1 Answer 1

up vote 1 down vote accepted

You typically only impersonate while handling a client request. The rest of the time, the service is configured to use a system account (usually THE system account) that has (or is configured to have) full privileges to do its necessary tasks.

The security issue to watch out for is of course, ensuring that a user can't elevate themselves to that account.

When you install a service, one of the things you need to put some thought into is choosing the service account. Either using one of the built in accounts, or creating a special purpose account for your service. There are built in accounts for "LocalService", "NetworkService", "LocalSystem" iirc, otherwise you can pick an existing or new user or administrative account (not recommended).

When you create the files (assuming you don't pass any explicit ACL information) they inherit the inheritable access rights of the owning folder. These you setup such that "users (a group including your impersonated users)" have create rights. "owners" have read/write. and "your default service account" has full control.

This means that your service, when not impersonating anyone, has full access to the files. When impersonating someone, can only read/write that particular users file.

Any regular users logged onto the Server will also not be able to access the files (unless they happen to be the impersonated users). Administrators can take ownership however, and then assign themselves read/write access. There is no defense (nor should there be) from local administrators.

share|improve this answer
So the way to go is to do impersonation for all inbound call and let the filesystem handle the Security (in practice) and have the service it self running under the local system account in order to process files written by other users ? –  ROAR Mar 15 '11 at 9:44
A lot depends on who you are trying to protect the files from. In the context of local logons: Regular users on the PC can be denied access to the files. Administrators always have the right to take ownership and re-assign access to themselves. Services run, iirc, in the context of a SYSTEM account by default (but Im sure the SCM can be configured to run them under other accounts), which can be explicitly added to an objects ACLs if not already there. –  Chris Becke Mar 15 '11 at 11:06
I want to make sure nobody connect to the interface and tries to perform either store or query operations unless they are an authenticated user and make sure that they only can read what they would be able to read by using the Windows explorer. –  ROAR Mar 15 '11 at 11:20
In that case, yes: Let the filesystem handle the security by ensuring that all RPC calls are performed while impersonating the relevant user. The rest of the time the service account should have the access necessary (As long as you've setup the default ACL's properly). –  Chris Becke Mar 15 '11 at 11:23

Your Answer


