SECURITY Create assembly without external access create assembly searchSafe from c:typessearchSafe.dll with permission_set = safe go Then, use the symbolic names to define two versions of the same user- defined function. Create function on assembly with external access create function WebSearchEA(@sym nvarchar(10)) returns real external name searchEA:SearchEngine::WebSearch go Create function on assembly with no external access create function WebSearchSafe(@sym nvarchar(10)) returns real external name searchSafe.SearchEngine.WebSearch go now, attempt to use them declare @a REAL this will work properly SET @a = dbo.GoogleSearchEA( SQL+Server+Yukon ) PRINT @a this fails with a code access security violation SET @a = dbo.WebSearchSafe( SQL+Server+Yukon ) PRINT @a What happens when a stored procedure that has limited access (SAFE) attempts to call a stored procedure that is declared as UNSAFE? Because of the way the stack walk works, this enforces security in a way that is even more restrictive than SQL Server ownership chains. Remember that an ownership chain is only checked when it is broken that is, when the caller is not the owner of the object she attempts to access. The stack walk checks permissions all the way up the stack; failing permission at any level will cause the call to fail. Because System.Security.dll is not allowed, there is no way for an assembly to do an Assert and subvert the stack walk. This may also have some performance impact since it implies that every stack walk goes all the way up to the top. Code access security provides an additional level of security, regardless of the user principal that executes the code.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Tomcat Web Hosting services