I’ve been playing around with an Amazon EC2 setup recently as I’ve started looking into the whole world of RDF hosting. I’ve worked with online virtual servers for a good few years now but not too much with the Amazon AWS offerings and as with all things in life, especially technology, change can be tedious. As such, the last day has been one spent getting the rudimentary modules up and running in order for the server to be operational. Ports have needed to be opened so as to allow in Remote Desktop Sharing client connections. FTP servers have needed to be established (I’m still working on getting passive FTP to work through the two Firewalls that exist in this setup – the EC2 one and the inbuilt Windows Firewall) and a web server that supports ASP.NET v.4 had to be installed and configured.
A myriad of different and quite idiosyncratic issues came up as I worked through this process. In this blog post I will deal with just one of these problems and that is the issue of how to go about getting access to the file system from within your ASP.NET app.
Windows apps and services are run by users. Now in the case of the apps that you run yourself, such as MS Word, this will usually be the user account that you logged in as. If you have administrator rights then you are entitled to quite a bit more control than if you were logged in with just standard user access rights. The problem arises when you are working with services or apps such as HTTP and FTP servers that run in the background. These in themselves often spawn off their own child services and for my purposes the most relevant of these are ASP.NET applications. So we have the main HTTP service running as a particular user and then the ASP.NET app that it launches as a result of a request from the client might (and in fact generally will) run as a different user account altogether.
So what, you might ask, is the importance of this? And your scepticism might indeed be well founded if your ASP.NET app did nothing more than manipulate data within its own space. Here’s a simple example. You build an ASP.NET web service that adds two numbers together that it receives as input from the client. There are no problems here with user accounts as all the resources that are needed are found in-house.
Problems arise, however, when you want to get at an external resource, the most obvious of which is the file system. In this case, the user account that your ASP.NET app runs within may not have privileges sufficient to add files or folders to a particular folder. In fact, it may not even be able by default to read from a particular folder. And for various reasons, file systems within web servers tend to be quite locked down in this respect.
As it turns out your ASP.NET app runs in what is called an Application Pool within the IIS set of services. The question then presents itself: which user account is associated with each of these Application Pools? While the user account can be changed by the server’s administrator, the default user account for each Application Pool is called “IIS AppPoolNAME_OF_APPPOOL” where NAME_OF_APPPOOL is the name of the Application Pool in question.
With this information in hand you can now simply go to the folder that you want your ASP.NET app to have access to and edit its security settings from within its properties dialog. Add the user account that is associated with the Application Pool for your ASP.NET app and give this newly added user the privileges that you deem appropriate.
And hey presto, your ASP.NET APP should now be able to access the file system resources that you want it to have!