Hog3 PC, cant get it to start

[quote=c_muenchow;42660]The reason for this is not yet fully known.


i've pointed this out a couple of times, but here's some more info, a quick fix, and a test for acceptance that you can perform yourself.


UAC auto-elevation
[INDENT]User ACCOUNT Control (and Windows NT, since inception) works slightly differently from what you've described.

there's a very important distinction between a PRIVILEGE and a PERMISSION - a PRIVILEGE describes access to an operation (i.e. a set of functions) and a PERMISSION describes access to a resource such as a file or registry key.


the RegOpenKey() function is what one calls to act upon an interest in a registry key or its value.

considering that standard users have unlimited access to their own HKCU registry hive, it follows that RegOpenKey() does not assert that a standard user have any elevated PRIVILEGEs assigned to their tokens.


in other words, standard users are allowed to call the RegOpenKey() function.


however, if a standard user asks RegOpenKey() to operate on a resource under HKLM, that resource will likely have a permission set applied that allows a standard user "Read Only".

so if a standard user uses RegOpenKey() to open a "Read Only" resource for Writing, RegOpenKey() will correctly return "Access Denied".


this is where the distinction betweeen PRIVILEGE and PERMISSION becomes important -

UAC will not auto-elevate a 3PC process because: a standard user token holds all PRIVILEGEs necessary to call every function that 3PC imports from the Win32 API's; even if a function returns "Access Denied", that function has successfully been called, run to completion, and returned a value to its caller.


Again, the auto-elevation aspect of UAC is intended to solve problems with PRIVILEGEs, not PERMISSIONs.

for examples of PRIVILEGEs that will cause UAC to auto-elevate, see Privilege Constants (Windows)
[/INDENT]

UAC Virtualization
[INDENT]in addition to auto-elevating when PRIVILEGE requirements are detected, UAC provides facilities for dealing with an application's PERMISSION requirements.

specifically, when a standard user tries to write to "Program Files" or HKLM, they should get "Access Denied".

instead, UAC intervenes by redirecting those write operations to targets located in an area that the standard user *does* have permission to modify.


in the case of a standard user attempting to create a file named "~lock" in "C:\Program Files\Flying Pig Sytems\Hog3PC", the file "~lock" is instead written to "C:\Users\Standard User\AppData\Local\VirtualStore\Program Files\Flying Pig Systems\Hog3PC"

similarly for "HKLM\SOFTWARE\Flying Pig Systems" registry entries, there are standard-user-accessible keys under "HKEY_USERS\{SID}_Classes\VirtualStore\MACHINE\SOFTWARE\Flying Pig Systems"


both operations, reading to and writing from these redirected resources, are handled by UAC Virtualization, and are completely transparent to the 3PC applications.


So why is this causing problems with Hog3PC?

well, it's because of some permissions set on the registry by the 3PC installer.

specifically, the MSI LockPermissions table applies permissions to the ProductVersion, EnlargeToolbarButtons, and InstUpgrade entries.

the set of permissions applied "forget" to allow standard users "Read" access.

and, unfortunately, since the actual "Software\Flying Pig Systems" keys are non-existant until these values are created with their errant permissions, the actual "Software\Flying Pig Systems" key assumes the permissions used to create ProductVersion, etc.

so, when 3PC is run as a standard user, it: does not have permission to read its own registry values, throws an fps::exception when trying to read its own registry values, and is unable benefit from UAC Virtualization when writing to these values.
[/INDENT]


please find attached a set of MSI transforms that cause these registry keys/values to be created with the default permissions inherited by HKLM\SOFTWARE.



to use them:[LIST=1]
provision a "greenfield" Windows 7 or Windows Vista machine, which has never had 3PC installed to it (because other registry values are created at runtime, the 3PC installer does not know to remove them during an UNINSTALL, and the errant permissions will still be in place)
place Hog3PC-Win32-golden_3-1-0-2672.msi and 2672-LUA.mst into a single folder
open a command prompt
cd to this folder
msiexec/i Hog3PC-Win32-golden_3-1-0-2672.msi TRANSFORMS=2672-LUA.mst
drive the install sequence as normal
launch launcher as a standard user
there are a few other areas that need their permission sets refined, such as the Services - these need to be modified to allow standard users to control starting and stopping.

but overall, the adjustment of a few permissions is very, very little work required to achieve compatibility with a standard user context.


Chris - i'd very much appreciate it if you took this to Robbie's attention.

[quote=c_muenchow;42660]The reason for this is not yet fully known.


i've pointed this out a couple of times, but here's some more info, a quick fix, and a test for acceptance that you can perform yourself.


UAC auto-elevation
[INDENT]User ACCOUNT Control (and Windows NT, since inception) works slightly differently from what you've described.

there's a very important distinction between a PRIVILEGE and a PERMISSION - a PRIVILEGE describes access to an operation (i.e. a set of functions) and a PERMISSION describes access to a resource such as a file or registry key.


the RegOpenKey() function is what one calls to act upon an interest in a registry key or its value.

considering that standard users have unlimited access to their own HKCU registry hive, it follows that RegOpenKey() does not assert that a standard user have any elevated PRIVILEGEs assigned to their tokens.


in other words, standard users are allowed to call the RegOpenKey() function.


however, if a standard user asks RegOpenKey() to operate on a resource under HKLM, that resource will likely have a permission set applied that allows a standard user "Read Only".

so if a standard user uses RegOpenKey() to open a "Read Only" resource for Writing, RegOpenKey() will correctly return "Access Denied".


this is where the distinction betweeen PRIVILEGE and PERMISSION becomes important -

UAC will not auto-elevate a 3PC process because: a standard user token holds all PRIVILEGEs necessary to call every function that 3PC imports from the Win32 API's; even if a function returns "Access Denied", that function has successfully been called, run to completion, and returned a value to its caller.


Again, the auto-elevation aspect of UAC is intended to solve problems with PRIVILEGEs, not PERMISSIONs.

for examples of PRIVILEGEs that will cause UAC to auto-elevate, see Privilege Constants (Windows)
[/INDENT]

UAC Virtualization
[INDENT]in addition to auto-elevating when PRIVILEGE requirements are detected, UAC provides facilities for dealing with an application's PERMISSION requirements.

specifically, when a standard user tries to write to "Program Files" or HKLM, they should get "Access Denied".

instead, UAC intervenes by redirecting those write operations to targets located in an area that the standard user *does* have permission to modify.


in the case of a standard user attempting to create a file named "~lock" in "C:\Program Files\Flying Pig Sytems\Hog3PC", the file "~lock" is instead written to "C:\Users\Standard User\AppData\Local\VirtualStore\Program Files\Flying Pig Systems\Hog3PC"

similarly for "HKLM\SOFTWARE\Flying Pig Systems" registry entries, there are standard-user-accessible keys under "HKEY_USERS\{SID}_Classes\VirtualStore\MACHINE\SOFTWARE\Flying Pig Systems"


both operations, reading to and writing from these redirected resources, are handled by UAC Virtualization, and are completely transparent to the 3PC applications.


So why is this causing problems with Hog3PC?

well, it's because of some permissions set on the registry by the 3PC installer.

specifically, the MSI LockPermissions table applies permissions to the ProductVersion, EnlargeToolbarButtons, and InstUpgrade entries.

the set of permissions applied "forget" to allow standard users "Read" access.

and, unfortunately, since the actual "Software\Flying Pig Systems" keys are non-existant until these values are created with their errant permissions, the actual "Software\Flying Pig Systems" key assumes the permissions used to create ProductVersion, etc.

so, when 3PC is run as a standard user, it: does not have permission to read its own registry values, throws an fps::exception when trying to read its own registry values, and is unable benefit from UAC Virtualization when writing to these values.
[/INDENT]


please find attached a set of MSI transforms that cause these registry keys/values to be created with the default permissions inherited by HKLM\SOFTWARE.



to use them:[LIST=1]
provision a "greenfield" Windows 7 or Windows Vista machine, which has never had 3PC installed to it (because other registry values are created at runtime, the 3PC installer does not know to remove them during an UNINSTALL, and the errant permissions will still be in place)
place Hog3PC-Win32-golden_3-1-0-2672.msi and 2672-LUA.mst into a single folder
open a command prompt
cd to this folder
msiexec/i Hog3PC-Win32-golden_3-1-0-2672.msi TRANSFORMS=2672-LUA.mst
drive the install sequence as normal
launch launcher as a standard user
there are a few other areas that need their permission sets refined, such as the Services - these need to be modified to allow standard users to control starting and stopping.

but overall, the adjustment of a few permissions is very, very little work required to achieve compatibility with a standard user context.


Chris - i'd very much appreciate it if you took this to Robbie's attention.