谈到ASP.NET程序的权限，一般可分为两种：
1) 账户的权限。
2) 代码的权限。
账户的权限可以限制运行在这个账户下的所有ASP.NET程序能进行什么样的操作，而代码的权限是ASP.NET程序里独有的，它规定了ASP.NET程序能够访问什么样的资源，比如数据库，文件等等。他们对ASP.NET程序是共同影响的，简单地说，ASP.NET程序表现出来的是他们共同作用的交集。
在IIS 5中，Application Pool的默认配置账户是ASPNET。在IIS 6/7中有点不同，ASPNET账户被替成Network Service。以IIS 7为例，如果你使用的是默认的Network Service，那么你的ASP.NET程序能访问的资源都是受Network Service限制的，换句话说，这个账户能访问什么资源，你的ASP.NET程序才能访问资源。Network Service在默认情况下，是可以读写IIS wwwroot文件夹下的所有文件以及在ACL的控制下来访问其他文件夹。
Scenario 1: 在Visual Studio下开发的时候，我们运行Visual Studio的账户是系统账户(登录机器的账户)，这个账户的权限比Network Service要大，因而出现一旦把程序部署到IIS中就有错误的情形时，大多可以先从这方面考虑。
Scenario 2: 在以windows集成验证方式连接数据库时，有时也会碰到Network Service账户不能Login的情形，这也是由于在开发时是用系统账户登录数据库的，而在部署到IIS后，是用Network Service来连接数据库。因而需要将Network Service账户添加到数据库中。
代码的权限在ASP.NET中叫做Code Access Security(CAS). 它规定了这个ASP.NET程序能够访问哪些资源。很明显，在一些情况下，账户权限并不能很方便的限制ASP.NET程序能做什么。利用CAS，我们可以限制ASP.NET程序是否能进行文件操作，是否能访问数据库资源。在ASP.NET的配置文件中，它分有5个不同的等级，通过设置不同的等级可以限制程序的访问资源。如果需要详情的话，建议大家可以查看这篇文章：
http://msdn.microsoft.com/en-us/library/ms998326.aspx
Scenario 3: ASP.NET程序部署到付费空间上后便不能创建文件了。这是因为服务器在machie级别定义了CAS，限制所有运行在这台机器上的ASP.NET不能进行文件操作。这样做的目的主要是为了保护服务器的安全。
同时，根据程序需要，我们也可以使用impersonate(通常在windows验证时会用到)。它可以模仿一个特定用户，这样的话，这个thread就运行在这个特定账户上。在域资源的访问中，这是一个很不错的手段来对不同的用户进行限制。
Have a nice day!