Home/ Questions/Q 6191835
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T02:50:12+00:00

Curious to know why my 2.0 .net application is being allowed to execute when

  • 0

Curious to know why my 2.0 .net application is being allowed to execute when I have restricted the permissions assigned to the assembly.

I’ve created a new Code Group at the Enterprise level which will match for any assembly with a particular digital signature. The code group has been set so that only permissions from the associated permission set will be used and also that lower policy levels will not be evaluated.

Running the .Net 2.0 PermCalc states that my application needs the following permissions:

  • UnmanagedCode,
  • Environment
  • FileIO
  • Registry
  • Reflection

I’ve assigned to my custom code group the permission for unmanaged code but nothing else.

The first method in my application demands all of the above permissions upfront so I can display a sensible message to the user before exiting.

Running the .NET 2.0 Configuation “Evaluate Assembly” tool on my assembly indeed shows that my application will only be given the UnmanagedCode permission.

However when I execute my application is runs and completes, quite obviously doing various FileIO and Registry operations.

My app is signed with the digital signature that should match the restricted code group.

Can anyone explain why this works.

Note: My ultimate aim is to make sure that my application does not crash horribly if executed from a network share. I would have liked to check the assembly evidence zone is My_Computer but I can no longer do that with .NET 3.5 SP1. See FullTrust On the LocalIntranet

Thanks in advance for any help/suggestions.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you have configured your CAS policy correctly, then chances are that your application isn’t being denied the permissions you expect because it is not being run under the CLR whose policy you configured. Do you perhaps have 32-bit and 64-bit CLRs installed on the same machine?

    Another possibility might be that your “early check” demand is in the wrong place. Is it directly in your application’s Main method? If so, when the demand runs, there won’t be any of your application code on the call stack that is verified. If this is the problem, simply moving the demand into another method invoked from Main should allow the demand to fail.

    • 0