SQL Server 2005 provides three security-permission settings that you can use to specify whether the database system should execute code in safe or unsafe areas outside the SQL Server environment. As you work with functions that venture outside of the "safe" SQL Server environment, you'll have to become aware of mechanisms Microsoft has put in place to prevent code from accessing "forbidden" areas or resources. Part of this protection layer involves technology known as code access security and a whole new regimen of permissions for your CLR code.

  • SAFE, the default, is the most restrictive permission setting. Code that an assembly with SAFE permissions executes can't access external system resources such as files, the network, environment variables, or the registry. You use this setting if SQL Server doesn't trust the CLR assembly (which makes the name SAFE seem like a misnomer). This designation tells the server to restrict the assembly code's external references to protect itself and the rest of the operating environment.
  • EXTERNAL_ACCESS lets assemblies access certain external system resources such as files, networks, environmental variables, and the registry—but apparently not the RSA encryption classes. I expected to be able to access these classes, but I couldn't. When using this setting, SQL Server assumes the code is moderately trustworthy, meaning the server can more fully (but not completely) trust the assembly code to stay within its boundaries.
  • UNSAFE gives assemblies unrestricted access to resources, both within and outside SQL Server. Code executing from within an UNSAFE assembly can call unmanaged code. Generally speaking, unmanaged code is code outside the .NET Framework, such as COM-based DLLs or other code that the Framework didn't implement. I had to use this designation to get the example assembly in the main article to execute without a permissions violation. This setting says the code is fully trusted and has rights to do whatever it's called upon to do.