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
