SQL Server 2005SQL代码安全之权限(2)

KeyContainerPermission 不受限制 -

SqlClientPermission 不受限制 -

EventLogPermission 受限制 仅限于本地主机且仅限于系统管理员

DnsPermission 不受限制 -

SocketPermission 受限制 仅限于IP地址

WebPermission 受限制 仅能通过HTTP存取本地主机

SmtpPermission 受限制 仅能进行连接存取

DistributedTransactionPermission 不受限制 -

NetworkInformationPermission 受限制 仅能通过Ping方式存取

StorePermission 不受限制 -

　　上面不受限制的FileIOPermission可能看起来有点令人担心，因为，它意味着，从CLR的角度来看，代码能存取磁盘上的任何位置。但是切记，该代码仍然运行于本地服务帐户的操作系统安全限制下。因此如果该帐户不能存取一个文件的话，那么SQLCLR代码也不能存取。

　　典型地，本地服务帐户是一种具有极强权限的帐户，因此存在滥用的可能性。为此，我们一般把对这些程序集的存取权限仅授予那些具有服务帐户信任度的登录并且不使用本地系统帐户作为SQL Server的服务帐户。

　　值得注意的是，借助于EXTERNAL_ACCESS权限集，你可以使用一个更传统型的ADO.NET连接串来连接到在同一个SQL Server实例（SQLCLR代码在其中运行）中的一个数据库。这需要SqlClientPermission以便你能够使用一个除了"上下文连接"串以外的连接-用以读取当前实例中的数据，指定通常的服务器命名，凭证，等等。然而，我也无法找到为什么你要这样做的理由，但是既然我们可以进行选择，也是一件好事，对吗？

　　(3) UNSAFE

　　这个UNSAFE权限集是赋予所有权限的SQLCLR等价物，在这种情况下，CLR挂起所有的许可权检查。它接受单个的不受限制的SecurityPermission权限，这是CLR的授予所有权限的方式。

　　潜在地，一个UNSAFE程序集能够完成各种"危险性"的动作，因为它属于内在地被信任的代码。例如，它能调用非托管代码，例如COM组件和原始Win32 API。它还受限于服务帐户的操作系统许可权，但是CLR不会限制它存取任何资源的能力。

　　因为UNSAFE是如此的不安全，所以，只有一个sysadmin能够创建这种类型的程序集。　

二、 访问外部资源

　　因为访问外部资源需要与操作系统进行交互，所以，当代码尝试存取外部的资源时，存在多种要遵守的规则。

　　对于SAFE代码来说，这种规则是简单的：如果它试图存取一个外部的资源，那么存取将被否认并且它引发一个异常。就是这些。

　　对于EXTERNAL_ACCESS和UNSAFE的情况，则复杂些：

　　· 规则1:如果代码在一个SQL Server登录的安全上下文下执行（也就是说，还没有被映射到一个Windows用户或组），那么存取将被禁止并且引发一个异常。一个SQL登录并不拥有SQL Server外的任何许可权，因此这是很重要的。

　　· 规则2:如果代码在一个被映射到一个Windows登录的登录下执行，那么进行外部存取的执行上下文就是该登录的执行上下文。如果该用户能够存取Windows中的资源，那么该代码成功。如果不是，存取被否认并且引发一个异常。

　　· 规则3:如果调用者不是原始的调用者（已经进行了一个执行上下文切换)，那么存取被否认并且引发一个异常。