Winreg

[R Pasco]

 My code was just experimental and will be much refined in the future which
will include specific exception catches. Connecting to the local registry
is to 'go the last yard' for a full-blown implementation.

I had a hard time grasping the Windows registry concept of having to first
get a key handle for the parent keypath and then specifying an already
existing fina/'leaf' key as a string in order to simply read the key's
valuename/value data. Who can tell what they were thinking at the time! It
seems like a good idea to "abstract" this out since it seems overly
complicated and needlessly confusing.

Thanks for your extensive info. Its too bad this isn't published in the
python winreg/_winreg modules' info.
Ray Pasco

On Fri, Jul 31, 2020 at 12:43 AM R Pasco <pascor22234 at gmail.com> wrote:

> My code was simply experimental and will be much refined in the future
> which will include specific exception catches. Connecting to the local
> registry is to go the 'last yard' for a full implementation.
>
> I had a hard time grasping the Windows registry concept of having to first
> get a key handle for the parent keypath and then specifying an already
> existing final or 'leaf' key as a string in order to simply read the key's
> valuename/value data. Who can tell what they were thinking at the time! It
> seems like a good idea to "abstract" this out since it seems overly
> complicated and needlessly confusing.
>
> Thanks for your extensive info. Its too bad this isn't published in the
> python winreg/_winreg modules' info.
> Ray Pasco
>
>
>
> On Thu, Jul 30, 2020 at 11:53 PM Eryk Sun <eryksun at gmail.com> wrote:
>
>> On 7/30/20, R Pasco <pascor22234 at gmail.com> wrote:
>>
>> >   access rights must be set to [winreg.KEY_ALL_ACCESS |
>> winreg.KEY_WOW64_64KEY
>>
>> It's a bad practice to request more access than you require, at the
>> very least because the request may fail with access denied for no good
>> reason.
>>
>> KEY_ALL_ACCESS includes all applicable standard rights (WRITE_OWNER,
>> WRITE_DAC, READ_CONTROL, DELETE) and all key rights (KEY_QUERY_VALUE,
>> KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY,
>> KEY_CREATE_LINK). For an existing key, do you need to change the
>> owner, read and modify the security, delete the key, set a symlink,
>> etc? It looks like you just need to set a value, i.e. KEY_SET_VALUE.
>>
>> >   winreg.KEY_WOW64_32KEY] (??? Why does this also work ?)
>>
>> By default a 64-bit process doesn't see redirected keys, but if you
>> need to access them, use KEY_WOW64_32KEY in the desired access.
>> Normally a 32-bit process under WOW64 sees redirected keys, and if you
>> need to access the non-redirected keys, use KEY_WOW64_64KEY.
>>
>> Note that KEY_WOW64_64KEY and KEY_WOW64_32KEY access modes only affect
>> runtime redirection. As with the standard MAXIMUM_ALLOWED access mode,
>> they're not assignable rights that can be granted or denied in a key
>> object's access control list.
>>
>> >  with winreg.ConnectRegistry( None, hive ) as hivehndl
>>
>> There is no need to call ConnectRegistry here. By default, predefined
>> handles are resolved to local key handles. Also, if you actually need
>> to access a remote machine, note that it's nonsensical to try to
>> connect to HKEY_CURRENT_USER. The API allows it, but why would one
>> assume that the remote machine will have a profile for the current
>> user's SID? The remote system will most likely just connect to a
>> handle for the default user profile.
>>
>> > The key HKEY_LOCAL_MACHINE:SOFTWARE requires KEY_WOW64_64KEY
>> > to be 'OR'ed. Winreg gives no indication of this requirement, but the
>> > Windows doc "Redirected, Shared, and Reflected Keys Under WOW64" does
>> > specifically mention  HKEY_CURRENT_USER :SOFTWARE as needing this added
>> > access.
>>
>> At the machine level, the software hive is stored on disk at
>> "%SystemRoot%\System32\config\SOFTWARE" and mounted at
>> "\REGISTRY\MACHINE\SOFTWARE". For a WOW64 process, by default there is
>> extensive runtime redirection of keys in this hive to the subkeys
>> "WOW6432Node" and "Classes\WOW6432Node".
>>
>> At the user level, there are two hives mounted. The user profile is
>> stored on disk at "%USERPROFILE%\NTUSER.DAT" and mounted at
>> "\REGISTRY\USER\<SID>", where "<SID>" is the string form of the user's
>> security identifier (e.g. "S-1-5-21-<RID1>-<RID2>-<RID3>-<RID4>"). For
>> a WOW64 process, there is no redirection of subkeys that are
>> physically stored in this hive.
>>
>> The user's software classes hive is stored on disk at
>> "%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat" and mounted at
>> "\REGISTRY\USER\<SID>_Classes". In the user profile, the
>> "Software\Classes" key is a symbolic link to the latter. For a WOW64
>> process, some subkeys in the classes hive are redirected to subkeys in
>> "WOW6432Node" (i.e. "Software\Classes\WOW6432Node"). It's just a
>> limited subset, including "CLSID", "DirectShow", "Interface", "Media
>> Type", and "MediaFoundation".
>>
>> ---
>>
>> One never sees "\REGISTRY\MACHINE" and "\REGISTRY\USER" in the
>> registry API because it's designed to always use the "RootDirectory"
>> handle in the native NT object attributes [1]. For local access, the
>> API maps real handles for "\REGISTRY\MACHINE" and "\REGISTRY\USER" to
>> the predefined pseudo-handles HKEY_LOCAL_MACHINE and HKEY_USERS.
>> Similarly, HKEY_CURRENT_USER is mapped to a handle for
>> "\REGISTRY\USER\<SID>", where "<SID>" is the string form of the user's
>> security identifier. For remote access via RegConnectRegistryW (i.e.
>> winreg.ConnectRegistry), the predefined handles are mapped to
>> remote-procedure-call (RPC) handles that proxy real key handles on the
>> remote system.
>>
>> [1]
>> https://docs.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_attributes
>>
>