Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Get registry key name from hKey?

113 views
Skip to first unread message

Chuck Chopp

unread,
May 24, 2001, 9:20:16 PM5/24/01
to
If I have an hKey value that is for a registry key that was opened with
RegOpenKeyEx(), is there any possible way to use the hKey value to
determine what the key's name is?

For example, I have some code that receives an hKey value passed in as a
parameter. If I have a problem accessing that key, I want to generate
some error log information that includes the key's name [preferrably
fully qualified name] and the hive under which it is located.

This code that I'm working on is supposed to disable/enable ACL
inheritance for the DACL and the SACL on registry keys. I need to do
this with the low level security API functions because it needs to work
reliably across the WinNT/Win2K platforms. Doing this with the low
level security API functions was OK for folders and files because they
are always handled as string values and it is possible to parse the
string to figure out what the parent folder is for any given folder or
file. However, if I've got a registry key handle [but not the key's
name and hive] then I'm at a loss to figure out how to determine what
the key's parent key is for the purpose of determining what ACEs may
need to be inherited when I re-enable ACL inheritance on a specified
key.

Any clues or hints here? Am I trying to do the impossible?

I've gone all through the Reg*() functions in the Platform SDK and none
of them seem to be able to return the desired information.

I tried a Google search and an MSDN search and no answers to this
question could be found via those sources.


TIA,

Chuck
--
Chuck Chopp

Chuck...@rtfmcsi.com http://www.rtfmcsi.com
ICQ # 22321532
RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651 800 774 0718 pager
80077...@skytel.com


David Janson

unread,
May 28, 2001, 7:07:04 PM5/28/01
to
| If I have an hKey value that is for a registry key that was opened with
| RegOpenKeyEx(), is there any possible way to use the hKey value to
| determine what the key's name is?

..

| Chuck Chopp
|
| Chuck...@rtfmcsi.com http://www.rtfmcsi.com
| ICQ # 22321532
| RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
| 103 Autumn Hill Road 864 801 2774 fax
| Greer, SC 29651 800 774 0718 pager
| 80077...@skytel.com

Chuck,

I certainly can't tell you to RTFM. Your research is as good as your
company name.

No, there is no API for doing this. Take a look at both RegMon and
HandleEx at http://www.sysinternals.com. Both of these tools either use
kernel-mode API hooking, or have reverse engineered an unexposed solution.
Unfortunately, you're going to have to re-evalute why you don't still have
the key name. You couldn't have a handle if you didn't have the key name
sometime in the past...

I'll have the security guys take a look and see if there is something
purely in the security world that will help, but I doubt there is and there
certainly are no registry APIs that will help.

David Janson
Windows Developers Support

Chuck Chopp

unread,
May 28, 2001, 8:08:27 PM5/28/01
to
David Janson wrote:

David,

I did get a response to a similar posting I made over in
microsoft.public.platformsdk.base and the answer to my question is to use the
function ZwQueryKey(). Apparently this function is documented in the NTDDK. I
don't have the NTDDK docs installed into my MSDN installation on my development
system so I've not been able to look into it, but some sample code was posted
along with the recommendation to use this function. I'm going to get the NTDDK
installed on my system and look over the docs for this function.

I'll also look up the other sources you mentioned. I like the code & utilities
available from the systms internals folks. I've used RegMon before, but maybe
its time to actually get down into the guts of RegMon to see how its really
working on NT/2K. At the very least it should prove to be quite educational.


Regards,

Chuck
--

David Janson

unread,
May 29, 2001, 8:22:41 PM5/29/01
to
| I did get a response to a similar posting I made over in
| microsoft.public.platformsdk.base and the answer to my question is to use
the
| function ZwQueryKey(). Apparently this function is documented in the
NTDDK.

Chuck,

Anything and everything documented in the DDK is very version specific.
Maybe it will work on other versions of NT, most likely it won't work on
9x. Maybe it will work from an application, but you'll never find it
documented for use by an application.

In other words, the DDK is for use by device driver developers. Microsoft
does not recommed its use in an application, nor will we support its use in
an application. In fact, we commonly have never tested these interfaces
from applications.

Chuck Chopp

unread,
May 30, 2001, 7:14:09 AM5/30/01
to
David Janson wrote:

> | I did get a response to a similar posting I made over in
> | microsoft.public.platformsdk.base and the answer to my question is to use
> the
> | function ZwQueryKey(). Apparently this function is documented in the
> NTDDK.
>
> Chuck,
>
> Anything and everything documented in the DDK is very version specific.
> Maybe it will work on other versions of NT, most likely it won't work on
> 9x. Maybe it will work from an application, but you'll never find it
> documented for use by an application.
>

Having this feature on Win9x is not an issue here since it is the security of
the key that I'm interested in managing. Given any hKey value that specifies
an open registry key, I need to get another hKey for the parent key of the
specified key. Once I have this I can make some determination about
inheritable ACEs, etc..., that might affect the specified key's security when
ACL inheritance gets re-enabled in the SD control flags of the specified key.
This has to be done with the low level security API functions and it must work
reliably across WinNT <---> Win2K.


>
> In other words, the DDK is for use by device driver developers. Microsoft
> does not recommed its use in an application, nor will we support its use in
> an application. In fact, we commonly have never tested these interfaces
> from applications.
>

That's understandable. The DDK documentation [which I've gotten a peek at
since yesterday] for the Zw*() functions indicates that those functions don't
do any of the parameter value error checking that is normally done by the
regular API functions. I can live with that. At the moment it is just
important to have this functional on WinNT and Win2K.

0 new messages