locked
UAC registry Virtual Store question for data sharing RRS feed

  • Question

  • Hello:

     

    I have two programs, say A and B. 

    By design, A is UAC elevated and B is not.

    A needs to read data that B saved in registry.

    However, since B is not elevated, it saved the data to the Virtual Store.

    The issue is, when A needs to read the data from registry,

    since A is elevated, it will get data from the real registry, not the Virtual Store.

    A won't see what B has put in the registry.

     

    How do I overcome this issue?

     

    Thank you.

    Wednesday, April 9, 2008 9:16 AM

Answers

  • Applications shouldn't rely on the existence of the Virtual Store. The correct approach is to modify application B to be LUA aware, such that it writes data to an appropriate per-user location and modify A accordingly. If it isn't possible to modify application B, then application A could be modified to read from the virtualised location in the registry directly (ie under HKCU\Software\Classes\VirtualStore) though this may break on future versions of Windows.

     

    If neither application A or B can be modified (because this is a deployment, rather than development issue), you could consider modifying ACLs on the appropriate HKLM registry keys (though be aware that this may impact security and stability).

     

    Wednesday, April 9, 2008 10:28 AM
  • HKCU won't work here if A must be run elevated - if the user is a standard user, then Application A and Application B are using seperate HKCU's.

     

    A correctly ACLed key somewhere under HKLM or a correctly ACLed folder under ProgramData (CLSID_COMMON_APPDATA or FOLDERID_PROGRAMDATA) could work, but like AndyCadley says, be aware of the security implications of that.

     

    Also, you should manifest your applications with a requestedExecutionLevel, including the one that doesn't run elevated ('asInvoker').

    Wednesday, April 9, 2008 8:29 PM
  • Thanks AndyCadley and David:

     

    Currently what I did to get around this issue is to let A to read data from HKCU\Software\Classes\VirtualStore, but I didn't know there will possible be future changed. Thanks for mentioning this.

     

     

    The other solution you mentioned was to modifying ACLs on the appropriate HKLM registry keys. I've never heard of this, would you please give a reference url or sample code?

     

    BTY, what is LUA arare? Does LUA mean "Loged on User Account"?

     

    Sincerely.

     

     

    Thursday, April 10, 2008 12:41 AM
  • >Currently what I did to get around this issue is to let A to read data from >HKCU\Software\Classes\VirtualStore, but I didn't know there will possible be future changed. Thanks >for mentioning this.

     

    This doesn't work right now, let alone in the future.  Application A could be using a different user's HKCU than application B if A is designed to run elevated.  Try running this as a standard user. Wink

     

    The best time for creating a shared, user-writable directory in a systemwide location is as part of your installation process - you can write your own code to do the ACL stuff, but you will probably find it easier to use whatever your install technology is.

     

    Here is a code sample, in any case (not necessarily for your scenario, but still, a good place to start)

    http://msdn2.microsoft.com/en-us/library/ms717798(VS.85).aspx

     

    'LUA' was what UAC used to be called before Vista was released.  I think it might stand for 'Least User Access'.

    Thursday, April 10, 2008 4:09 AM
  •  David Tyler Hunt wrote:

    This doesn't work right now, let alone in the future.  Application A could be using a different user's HKCU than application B if A is designed to run elevated.  Try running this as a standard user.

     

    True, but it's an optional "bodge" fix if you know that users will be Administrators and won't elevate to another account. I didn't mean for it to sound like a long term solution, so thanks for making that more clear than I did. Smile

     

     David Tyler Hunt wrote:

    'LUA' was what UAC used to be called before Vista was released.  I think it might stand for 'Least User Access'.

     

    Least Usable Authority or Limited User Account, depending upon whom you talk too.

    Thursday, April 10, 2008 1:41 PM

All replies

  • Applications shouldn't rely on the existence of the Virtual Store. The correct approach is to modify application B to be LUA aware, such that it writes data to an appropriate per-user location and modify A accordingly. If it isn't possible to modify application B, then application A could be modified to read from the virtualised location in the registry directly (ie under HKCU\Software\Classes\VirtualStore) though this may break on future versions of Windows.

     

    If neither application A or B can be modified (because this is a deployment, rather than development issue), you could consider modifying ACLs on the appropriate HKLM registry keys (though be aware that this may impact security and stability).

     

    Wednesday, April 9, 2008 10:28 AM
  • HKCU won't work here if A must be run elevated - if the user is a standard user, then Application A and Application B are using seperate HKCU's.

     

    A correctly ACLed key somewhere under HKLM or a correctly ACLed folder under ProgramData (CLSID_COMMON_APPDATA or FOLDERID_PROGRAMDATA) could work, but like AndyCadley says, be aware of the security implications of that.

     

    Also, you should manifest your applications with a requestedExecutionLevel, including the one that doesn't run elevated ('asInvoker').

    Wednesday, April 9, 2008 8:29 PM
  • Thanks AndyCadley and David:

     

    Currently what I did to get around this issue is to let A to read data from HKCU\Software\Classes\VirtualStore, but I didn't know there will possible be future changed. Thanks for mentioning this.

     

     

    The other solution you mentioned was to modifying ACLs on the appropriate HKLM registry keys. I've never heard of this, would you please give a reference url or sample code?

     

    BTY, what is LUA arare? Does LUA mean "Loged on User Account"?

     

    Sincerely.

     

     

    Thursday, April 10, 2008 12:41 AM
  • >Currently what I did to get around this issue is to let A to read data from >HKCU\Software\Classes\VirtualStore, but I didn't know there will possible be future changed. Thanks >for mentioning this.

     

    This doesn't work right now, let alone in the future.  Application A could be using a different user's HKCU than application B if A is designed to run elevated.  Try running this as a standard user. Wink

     

    The best time for creating a shared, user-writable directory in a systemwide location is as part of your installation process - you can write your own code to do the ACL stuff, but you will probably find it easier to use whatever your install technology is.

     

    Here is a code sample, in any case (not necessarily for your scenario, but still, a good place to start)

    http://msdn2.microsoft.com/en-us/library/ms717798(VS.85).aspx

     

    'LUA' was what UAC used to be called before Vista was released.  I think it might stand for 'Least User Access'.

    Thursday, April 10, 2008 4:09 AM
  • Thanks a lot, David.

    It's very helpful and I'll try it.

    Thursday, April 10, 2008 5:04 AM
  •  David Tyler Hunt wrote:

    This doesn't work right now, let alone in the future.  Application A could be using a different user's HKCU than application B if A is designed to run elevated.  Try running this as a standard user.

     

    True, but it's an optional "bodge" fix if you know that users will be Administrators and won't elevate to another account. I didn't mean for it to sound like a long term solution, so thanks for making that more clear than I did. Smile

     

     David Tyler Hunt wrote:

    'LUA' was what UAC used to be called before Vista was released.  I think it might stand for 'Least User Access'.

     

    Least Usable Authority or Limited User Account, depending upon whom you talk too.

    Thursday, April 10, 2008 1:41 PM
  • AndyCadley:

     

    Thanks for making it more clear.

     

    Sincerely,

    Pen

    Friday, April 11, 2008 12:27 AM