locked
CAS Policy Problem RRS feed

  • Question

  • I have an assembly deployed which demands a certain permission. This assembly is strong named and lives in the \bin directory.

    To make configuration "easy", I figured I'd add a new Code Group to my Runtime Security Policy using the .NET Configuration tool which grants Full Trust to my assembly. The Code Group is under All_Code and the Membership Condition of the Code Group looks for a strong name of an assembly using the public key of the assembly (derived by importing the .dll). I disregard name and version.

    Straightforward, right? It just doesn't work, though! Every time, my assembly fails the permission demand! In theory, it should have full trust, right?

    What could be going wrong?

    Thursday, February 1, 2007 1:13 AM

Answers

  • It sounds like the "\bin" directory that you mentioned is a local directory.  If so, have you modified your CAS policy to restrict the permissions of local assemblies?  If so, are any of the code groups marked as exclusive or level final?

    If the assembly isn't being loaded from the local drive, here are a few other questions:

    1. Did you create the new code group in the CAS policy of the client machine or the machine from which the assembly is being loaded?
    2. To which CAS policy level (enterprise, machine, or user) did you add the code group?
    3. Are you sure that it is your assembly that is failing the demand and not some other assembly on the call stack?  (If you're not sure, please post the full exception details, including call stack, as retrieved from its ToString method.)
    Monday, February 5, 2007 8:25 PM

All replies

  • It sounds like the "\bin" directory that you mentioned is a local directory.  If so, have you modified your CAS policy to restrict the permissions of local assemblies?  If so, are any of the code groups marked as exclusive or level final?

    If the assembly isn't being loaded from the local drive, here are a few other questions:

    1. Did you create the new code group in the CAS policy of the client machine or the machine from which the assembly is being loaded?
    2. To which CAS policy level (enterprise, machine, or user) did you add the code group?
    3. Are you sure that it is your assembly that is failing the demand and not some other assembly on the call stack?  (If you're not sure, please post the full exception details, including call stack, as retrieved from its ToString method.)
    Monday, February 5, 2007 8:25 PM
  • You can use caspol to determine what permissions are being granted to your assembly, and why.

    From the caspol command line help:

    caspol -rsg
    caspol -resolvegroup <assembly_name>
        List code groups this file belongs to

    caspol -rsp
    caspol -resolveperm <assembly_name>
        List permissions granted to this file

    You should verify that your assembly is being correctly resolved to the code group you created.

    Hope that helps,

    Stephen

    Monday, February 5, 2007 8:29 PM
  • As it turns out, SharePoint, by default, demotes the CAS permissions of the assemblies running in the bin directory. You can set the app to run the assemblies with elevated trust levels, but if you try to grant full trust to an assembly in the bin with elevated trust levels, you'll get a runtime error saying that SharePoint doesn't want you to do that.

    Interestingly enough, you can GAC the assembly and run it with elevated privilages no problem (but then you can't really attach a debugger).

    Thursday, February 15, 2007 3:23 AM