Question
I'm developing a small set of services that'll run side-by-side on the same computer. Each service should only have read access to it's own data directory:
c:\myservices\[serviceName]\data
In an ideal world, each service would run under its own user account, and I'd assign NTFS permissions accordingly. But for reasons more political that technical, each service will run under the same user account: service_account
Is there a programmatic way to tell the .NET runtime, "Even though my user account may technically have Read access to the entire file system, I'll only be accessing c:\myservices\[serviceName]\data via this process, and requests to read files from anywhere else should throw an exception (e.g. UnauthorizedAccessException)." ?
Underlying Reason
I'm worried that a remote anonymous user could pass in a malformed string indicating a resource of interest, that refers to a resource that he shouldn't be able to see:
..\..\windows\system32\someSensitiveFile
Now of course, I'll do everything in my power to check this input and make sure it only refers to items in c:\myservices\[serviceName]\data, but I'd sleep a lot better at night knowing the .NET runtime itself were acting as an extra layer of protection.
Other Approaches
There are some preemptive steps I can take. I could use NTFS to Deny Read access for the entire drive for service_account, and then grant access selectively to:
c:\myservices\[serviceName]\data, c:\myservices\[serviceName2]\data,c:\myservices\[serviceName3]\data
...And that's a good start. But since all three services run under service_account, there's still the possibility that service2 could be coerced into accessing something in the service3 data folder, for example.
Which again brings me to my question: In .NET 6, is there a way to Deny/Grant file access rights for the process programmatically, that is, at the code level, in such a manner that the resultant set of rights for the process are more restrictive than that of the user under which the process runs?