Why can my app write successfully to HKLM\Software under Vista?

  • Thread starter Thread starter Simon
  • Start date Start date
S

Simon

Everything I read consistently tells me that if UAC is enabled under Vista
(which it is on my PC) an ordinary application (post-install) which does not
have any kind of manifest at all, cannot write to the HKLM\Software area of
the registry. Instead, what is supposed to happen is that Virtualization is
supposed to redirect the write to

HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software

Well it doesn't. I run my app and change a per-machine setting and it
updates HKLM\Software no problems. Not only does it look to be updated fine
if I look at the HKLM\Software area in RegEdit, it still looks OK if I log
off and log back on using an ordinary (non-admin) account and look at
HKLM\Software there. If I run my app and change the per-machine setting
using the other account, sure enough it is changed when I log back on using
my first account.

In my first account, there do appear to be some settings in the
'VirtualStore' area but not many. Most of the settings appear not to be
virtualised.

What is going on? Any help with this would be much appreciated. The
documentation I am reading just does not match what I see.

Simon
 
Everything I read consistently tells me that if UAC is enabled under Vista
(which it is on my PC) an ordinary application (post-install) which does not
have any kind of manifest at all, cannot write to the HKLM\Software area of
the registry. Instead, what is supposed to happen is that Virtualization is
supposed to redirect the write to

HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software

Well it doesn't.
Click to expand...

First, you are running the app non-elevated right? If so, check the ACL on
the key in HKLM. There are areas that ordinary users can write to still.
Virtualization only happens if the user gets an access denied on write.
 
First, you are running the app non-elevated right?

That's right. I can run as a non-elevated admin or as a standard user (also
non-elevated - can they be elevated?). It doesn't make any difference.
check the ACL on
the key in HKLM. There are areas that ordinary users can write to still.
Click to expand...

OK - I hadn't got this at all. When my program is installed (for historical
reasons) the registry key for the application (i.e. the application subkey
within the company subkey, within HKLM\Software) is given Full Control
permission to Everyone, and this is inherited by all of its sub-keys. This
is the reason it's OK to write to these areas? Because they've already been
set with those permissions at install time?

So let me get this right - does this mean I don't need to bother about any
of this UAC stuff? That because I've given everyone permission to write to
my key anyway, I can carry on as normal with no problems? It just seems
counter to everything Microsoft seems to be pushing for...

Simon
 
check the ACL on
OK - I hadn't got this at all. When my program is installed (for historical
reasons) the registry key for the application (i.e. the application subkey
within the company subkey, within HKLM\Software) is given Full Control
permission to Everyone, and this is inherited by all of its sub-keys.
Click to expand...

That's why it is not getting virtualized. If Everyone already has
permissions the app writes fine to that area.
So let me get this right - does this mean I don't need to bother about any
of this UAC stuff? That because I've given everyone permission to write to
my key anyway, I can carry on as normal with no problems? It just seems
counter to everything Microsoft seems to be pushing for...
Click to expand...

It is counter to everything Microsoft has been pushing for. Applications
should not grant Everyone permission to modify global application settings
unless they really want any user to be able to modify how the application
works for any other user. Depending on what data the app stores in the
registry, that could get really bad. For instance, an app may specify
settings that cause code to get run. In that case a low-privileged user could
replace the code that gets run with malicious code. When a high-privileged
user runs the app the malicious code executes. It depends on the application
and on whether the computer is multi or single user how bad this is.
 
Back
Top