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 <pascor22...@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 <eryk...@gmail.com> wrote: > >> On 7/30/20, R Pasco <pascor22...@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 >> > -- https://mail.python.org/mailman/listinfo/python-list
