System.Threading.ThreadAbortException

.NET Exceptions – System.Security.SecurityException

Next up in our journey through our .NET Exception Handling series, today we’ll take a gander at the System.Security.SecurityException. System.Security.SecurityExceptions occur when the caller — that is, the executing user account — doesn’t have proper permissions to access a particular resource.

Throughout this article we’ll examine the System.Security.SecurityException in more detail, including where it sits in the .NET exception hierarchy, along with some code samples using C# that will illustrate how System.Security.SecurityExceptions might be thrown, so you can better understand how to handle them yourself. Let’s get to it!

The Technical Rundown

When Should You Use It?

Permissions can be a tricky thing to deal with during development, particularly as an application grows in size and scope, thereby requiring the use of additional libraries, modules, services, connections, and so forth. Each additional component added into the application is just another potential security risk, and something that needs to be properly managed with permissions that allow the application (and its own processes therein) to perform the tasks it needs to, while simultaneously disallowing unintended access.

Due to these potential security risks the .NET Framework includes a vast array of security-related capabilities. The entire System.Security namespace provides numerous classes and helpers designed to make security management as easy and robust as possible. And, of course, the System.Security.SecurityException we’re looking at today is among those many tools.

As previously mentioned, a System.Security.SecurityException is thrown when the application’s caller attempts to access a resource it doesn’t have permission for. These resources could be all sorts of things, but for our purposes here we’ll use a similar example to that given by the official documentation: trying to manipulate the Windows registry without appropriate permissions.

We’ll start with the full working code example below, after which we’ll break the code down a bit more to see what’s going on:

Since we’re trying to manipulate registry keys we start with the CreateRegistryKey() method:

The subKeyTree parameter is the registry key path we’re trying to create. The PermissionState state parameter is the permission state we want to use while attempting to make our registry change. To do so, we create a new PermissionSet and add a new RegistryPermission element with the state parameter value. Finally, we need to ensure that the current process doesn’t use any inherent permissions it may have from the operating system user account or the like, and instead, only uses the permissions we’ve granted within the method. This is exactly what the call to permissionSet.PermitOnly() accomplishes. With everything set we can then try to create the registry key with the CreateSubKey() method.

To test our CreateRegistryKey() method we first declare the registry key string, then call CreateRegistryKey() with PermissionState.None passed in:

Since the temporary permission set we used includes PermissionState.None it isn’t much surprise that this ended up throwing a System.Security.SecurityException at us:

In this case we can resolve our issue by passing PermissionState.Unrestricted to the CreateRegistryKey() method, which should ensure that our RegistryPermission object has unrestricted access:

Sure enough, this works just fine and our log indicates that the registry key was generated:

Opening regedit.exe and drilling down to that location in the registry also confirms that the registry entry was created.

In order to clean up after ourselves and not leave any unnecessary registry keys lying around, we’ve also defined the DeleteRegistryKey() method:

This effectively attempts to reverse the registry key creation process we performed earlier, also by using permission sets. The use of the underlying .NET method DeleteSubKeyTree() forces us to provide the parent key name to our method, rather than the full subkey tree as we did with CreateRegistryKey():

Once again we’re trying two different calls to the DeleteRegistryKey() method; one with no permissions, and one with unrestricted permissions. The log output result shows both an initial failure on the first call, followed by success on the second:

To get the most out of your own applications and to fully manage any and all .NET Exceptions, check out the Airbrake .NET Bug Handler, offering real-time alerts and instantaneous insight into what went wrong with your .NET code, along with built-in support for a variety of popular development integrations including: JIRA, GitHub, Bitbucket, and much more.