Base types, Collections, Diagnostics, IO, RegEx…
Registry Permission Basics
RegistryKey.CreateSubKey(string, RegistryKeyPermissionCheck, RegistrySecurity)
RegistryKey.OpenSubKey(string, RegistryKeyPermissionCheck, RegistryRights)
The fact that there are three different ‘security’ looking parameter types in these methods can be confusing, so this is just a quick, simple, blog to make clear what those parameters are for.
Let’s start with RegistrySecurity as it’s what most people probably think of when they think of a security parameter. An instance of the RegistrySecurity type is essentially a collection of RegistryAccessRules. The rules specify who is allowed to do what with the registry key. Each rule is a pairing of a user and a particular type of access indicated by a member of the registry rights enum (see the various registry rights listed in the next section). Each rule will indicate that the specified right is either allowed or denied for that user. This information can later be retrieved or changed with the RegistryKey.GetAccessControl and RegistryKey.SetAccessControl methods, but the CreateSubKey overload shown above allows the rules to be set immediately at the time of key creation so that there’s no lag between the key being created and the security going into effect. The rules specified here are persisted in the registry even after the instance of the registry key being created is gone.
While the RegistrySecurity type allows permissions to be set for a newly created registry key, the registry rights type is used to request permissions when opening a key. The registry rights enum contains the following members:
When opening a key, one or more of these rights can be requested. Only actions permitted by the rights requested will be allowed for the registry key that is opened. This parameter will do nothing to change what permissions users can have, as stored in the registry. It simply determines what rights this particular instance of the registry key will allow. Of course, requesting rights that were not allowed by the rules used in the registry security parameter when creating the key (or in the rules subsequently applied with a SetAccessControl call) will throw an exception.
If no rights are specified, default rights are requested based on the overload of OpenSubKey used:
This type is different from the previous two. While the RegistryRights and RegistrySecurity types actually determined the permissions that users had or were requesting, this type simply determines when we do permission checks. Selecting different values for the RegistryKeyPermissionCheck parameter will not change which rights the key has requested (if there is a RegistryRights or RegistrySecurity parameter, at least) but it will determine whether or not some checks are done once up front in the name of performance. Consider the three RegistryKeyPermissionCheck values that can be selected:
Here’s some sample code that demonstrates the concepts discussed above.
static void Main(string args)
//***** Creating a registry key
// Here, we use the registry rights enum to define some
// registry access rules.
RegistryAccessRule rule1 = new RegistryAccessRule(@"DOMAIN\user",
RegistryAccessRule rule2 = new RegistryAccessRule(@"DOMAIN\user",
// Allowing the delete permission when doing tests like this
// is a good idea because it makes cleaning up later simpler.
RegistryAccessRule rule3 = new RegistryAccessRule(@"DOMAIN\user",
RegistrySecurity rs = new RegistrySecurity();
// Here, we use the regitry security object to create a key
// and specify that the user may only read, set values, and delete the key.
RegistryKey rk1 = Registry.CurrentUser.CreateSubKey("TestKey",
//***** Opened a registry key
RegistryKey rk2 = Registry.CurrentUser.OpenSubKey("TestKey",
// Even though the user is allowed to set values, this next line would fail
// because the key was only opened with readkey permissions
// rk2.SetValue("Test", "Testing");
//***** Opening a registry key with RegistryKeyPermissionCheck
RegistryKey rk3 = Registry.CurrentUser.OpenSubKey("TestKey",
// Even if we removed the SetValues right from this key at this
// point in this program, the following line would secceed
// because the key was opened with ReadWriteSubTree permissions and
// the check is therefore only done when the key is created.
// This will throw a security exception because we're trying to
// request a permission we didn't give this key (write permissions)
// RegistryKey rk4 = Registry.CurrentUser.OpenSubKey("TestKey",
// RegistryRights.ReadKey |
// RegistryRights.SetValue |