Registry access in non-admin mode

Question

I've several long-standing apps written in Delphi that persist their settings in the registry. I've used HKEY_LOCAL_MACHINE for 'hard' settings such as configuration preferences and HKEY_CURRENT_USER for 'soft' info such as window positions, MRU lists etc.

Now my users are telling me that in non-admin (standard user) mode the apps dont work. Looking, I see that I'm not able to read a setting put into HKEY_LOCAL_MACHINE when the app was in admin mode.

What are my options for this? I know little about standard mode and how this affects access to the registry at all. Any info appreciated.

Answer 1

You can read from HKLM as a non-admin user; you just can't write to it.

Use TRegistry.Create(KEY_READ) when constructing it, and set the RootKey to HKLM.

var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create(KEY_READ)
  try
    Reg.RootKey := HKLM;
    // Read value here
  finally
    Reg.Free;
  end;
end;

You can also use TRegistry.OpenKeyReadOnly() when opening a specific registry key; this helps with non-admin access to areas of the registry as well.

Answer 2

Please see "Where to store program settings instead of HKEY_LOCAL_MACHINE?"

The top-voted answer is particularly useful.

Answer 3

Your options include (a) use an INI/XML config file in a location that doesn't require admin rights to access, or (b) modify the security on your own subkey in HKLM using a tool like SetACL (public domain).

The problem with option a is the change in folder arrangements between XP and Vista/W7. I believe Vista tightened up access to CSIDL COMMON APPDATA - standard users don't have write acess if memory serves. You may have to store them in your own folder and arrange access rights yourself. Annoying.

One interesting problem with option b is that there are now officious little tools in use in corporate environments that crawl the registry and "correct" access rights they think are wrong. We haven't encountered a problem with customers using these yet, but we are aware they exist. Given the performance of the registry, we still prefer the modified HKLM approach and will continue to do it for the foreseeable future.

Answer 4

One option, which I don't favour but will mention, is to give everyone (or a defined group etc) permission to access your key. There are various ways to do this, and there is code in the JCL that will do it, or you can use Regedit. But if you give permission (to that specific branch of HKLM) then it will work as you intended.

Answer 5

The other thing that nobody's mentioned here is the issue of registry virtualization on Vista & Win7 (at least). It may not be an issue in your particular scenario, but I thought I'd mention it anyway in case it is relevant.
Even if your user has admin rights, if your application is NOT running "elevated" on Vista/Win7, your app still won't be able to write to the "real" HKLM key that you think it is. It will be being read and written to a virtualized copy of the appropriate HKLM key that only that particular user sees.
By "elevated", I mean that you will have been prompted with a UAC prompt on Vista/Win7. Run Regedit.exe for example on Vista/Win7, and you will be prompted with a UAC prompt.
If you're on Vista/Win7, it's possible that this is the issue you describe when you say it's not possible to read a key/value that was written in admin mode. If so, this would be because your app has at some stage written what is now a virtualized key/value; your app will now only ever see that key/value, even if an administrator modifies the "real" value.
As others have said, your app should not try to write to HKLM. If you feel it does need to write to HKLM, then on Vista/Win7 your options are (and these options can be made to work fine on XP too):

• Add a manifest to your app requiring elevated admin rights as per this example.
• Split your functionality requiring HKLM access out into a separate COM library and instantiate it as an elevated COM object as and when you need it. This is more complicated, but is a reasonable way to refactor existing functionality.

Here's another SO question that addresses some of these issues.