通过

Request for the permission of type 'SecurityPermission' failed

  • 项目

When you get the following exception while executing a report on the SSRS or within Ax:

System.Security.SecurityException was unhandled
Message="Request for the permission of type
'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.”

this is probably because the permission set in the config file of the SSRS - which you can normally find here (SQL 2005):

C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer

is not configured correctly. The exception might be thrown for example because of the following line:

System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString();

To resolve that problem you have to look for the PermissionSet that is defined for the assembly that caused the exception. In this case this is System.Security-assembly.

In the web.config you can find the link to the rssrvpolicy.config file

    1:      <securityPolicy>

    2:        <trustLevel name="RosettaSrv" policyFile="rssrvpolicy.config" />

    3:      </securityPolicy>

and in the rssrvpolicy.config the definition of the PermissionSets:

    1:            <NamedPermissionSets>

    2:              <PermissionSet class="NamedPermissionSet" version="1" Unrestricted="true" Name="FullTrust" Description="Allows full access to all resources" />

    3:              <PermissionSet class="NamedPermissionSet" version="1" Name="Nothing" Description="Denies all resources, including the right to execute" />

    4:              <PermissionSet class="NamedPermissionSet" version="1" Name="Execution">

    5:                <IPermission class="SecurityPermission" version="1" Flags="Execution" />

    6:              </PermissionSet>

    7:              <PermissionSet class="NamedPermissionSet" version="1" Name="AxSessionPermissionSet">

    8:                <IPermission class="AxSessionPermission" version="1" Unrestricted="true" />

    9:                <IPermission class="SecurityPermission" version="1" Flags="Assertion" />

   10:              </PermissionSet>

   11:            </NamedPermissionSets>

In the CodeGroup-section are defined:

    1:              <CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Execution" Description="This code group grants MyComputer code Execution permission. ">

    2:                <IMembershipCondition class="ZoneMembershipCondition" version="1" Zone="MyComputer" />

    3:                <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Microsoft_Strong_Name" Description="This code group grants code signed with the Microsoft strong name full trust. ">

    4:                  <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293" />

    5:                </CodeGroup>

    6:                <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Ecma_Strong_Name" Description="This code group grants code signed with the ECMA strong name full trust. ">

    7:                  <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="00000000000000000400000000000000" />

    8:                </CodeGroup>

The tool CasPol.exe (part of the .Net SDK) will help you to identify the CodeGroup that the System.Security assembly belongs to. In the GAC folder of this assembly I did a CasPol –rsg (resolvesGroup) on this assembly:

image

Now we can see that this assembly belongs to the Microsoft_Strong_Name (line 3 in the CodeGroup excerpt) and is configured for FullTrust. With the –rsp (resolvesPermissions) you can visualize all permissions that are granted to this assembly (as defined in the FullTrust named PermissionSet):

image

When the exception was raised, this assembly was configured to ‘Nothing’ (line 3 of the NamedPermissionSets excerpt). The problem was resolved by granting this assembly FullTrust.

You can find a good article about CAS (Code Access Security) for the SSRS on msdn here.

Comments

  • Anonymous
    August 10, 2009
    Hi , Is it a good Idea to set the Full Trust for the assembly to run the reports, I too had a similar problem and I did FullTrust to my assembly? However, when we consider client scenarios, we dont have a control on the Installation done by them. I want to add some more to your inputs here, Setting FullTrust to the assembly enables you to achieve more out of SSRS and SSAS, for example here what I noticed: You can dynamically call MDX queries from you Business Logic of SSRS, thereby having more control over them to manipulate the data. We had a scenario in which we had to manipulate data in a matrix, and this approach helped me greatly. However, the solution was denied since it was playing around with the configuration. Regards,

  • Anonymous
    April 07, 2010
    How are you able to determine that the assembly belongs to "Microsoft_Strong_Name"? Also, how do you know the assembly was configured to "Nothing" when the exception was raised? Also, how do you go about granting an assembly "FullTrust"?

  • Anonymous
    August 10, 2011
    The comment has been removed