Search code examples
c#registrypermissionssystem.security

RegistryPermission error when call from a C# console app


Just looking for some pointer before I head down the wrong path. I have written small C# console app that opens, reads, writes and deletes from our users registry under both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER

Of course, I got it to work on my PC and all the test PC but one of our clients is getting an error when they try to run the .exe

System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.RegistryPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) at System.Security.CodeAccessPermission.Demand() at Microsoft.Win32.RegistryKey.CheckSubKeyReadPermission(String subkeyName) at Microsoft.Win32.RegistryKey.CheckOpenSubKeyPermission(String subkeyName, Boolean > subKeyWritable) at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) at EstateMasterClearReg.Program.Main(String[] args)

The action that failed was:

Demand. The type of the first permission that failed was: System.Security.Permissions.RegistryPermission The Zone of the assembly that failed was: Intranet

As I won't be able to test this on the client machines (and they said that they have the .exe running locally and are logged in as Admin) is there anything I can do to try and ensure that the app will run on any machine?

Do I need to use a strong name key and AllowPartiallyTrustedCallers or should I use System.Security.Permissions.RegistryPermission?

Thanks for your help.


Solution

  • Looks like they may be running your executable over the network. Have them try copying it to a local hard drive and run again. The permissions assigned to the executable differ between running it from a network share vs. running from the local file system.

    Alternatively, it could be possible that they have modified the default security settings, so that even if it is running locally, it is considered part of the Intranet zone. Check those, too.

    The tips here may also be helpful:

    http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx

    Note that if you give your assembly a strong name, you'll still need local security policy to be modified to give your assembly the appropriate permissions. The strong name by itself won't grant the additional permission required.