Click here to get back home

Permissions on HKCR\TypeLib

 HomeNewsGroups | Search | About
 microsoft.public.windows.server.security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Permissions on HKCR\TypeLib Will 03-19-2007
Get Chitika Premium
Posted by Will on March 19, 2007, 9:42 pm
Please log in for more thread options
First, can someone confirm that HKEY_LOCAL_MACHINE\SOFTWARE\Classes is the
same as HKEY_CLASSES_ROOT? Why did Microsoft split the references to the
same object as they did?

For Windows 2003, can someone confirm what should be the permission for each
class under HKCR\Typelib? On one computer here both Users and
Authenticated Users were removed not from Typelib, but just from the child
keys. Strange.

Is there any published documentation on what DACL permissions each of the
key nodes under HKCR should have?

--
Will



Posted by Roger Abell [MVP] on March 20, 2007, 1:16 am
Please log in for more thread options
> First, can someone confirm that HKEY_LOCAL_MACHINE\SOFTWARE\Classes is the
> same as HKEY_CLASSES_ROOT?

Yes. The first is the "real" key. The second a convenience alias.

> Why did Microsoft split the references to the same object as they did?

What is the question? "split" ??

>
> For Windows 2003, can someone confirm what should be the permission for
> each class under HKCR\Typelib?

You are joking, right ? There are 540 +/- of them on this XP
.\Typelib and all of its direct children I spot checked are only
strictly inheriting from HKCR

> On one computer here both Users and Authenticated Users were removed not
> from Typelib, but just from the child keys. Strange.
>

I have no grants to AU here

> Is there any published documentation on what DACL permissions each of the
> key nodes under HKCR should have?
>

punt (i.e. doubtful)



Posted by Will on March 20, 2007, 7:37 pm
Please log in for more thread options
>> For Windows 2003, can someone confirm what should be the permission for
>> each class under HKCR\Typelib?
>
> You are joking, right ? There are 540 +/- of them on this XP
> .\Typelib and all of its direct children I spot checked are only
> strictly inheriting from HKCR

I meant is there a single DACL that should apply to all of the child keys
under Typelib. Typelib itself on one machine had a different DACL than
all of its children.

When you get some complex registry structure that ends up having some nodes
simply be pointers to other parts of the registry, how can you determine
this relationship? Is there something in regedit that will reveal to you
that a key named x is actually a shortcut to another registry path?

When modifying (or verifying) a DACL, I guess it would be better to do so on
the true registry path rather than the reference to that path.

--
Will





Posted by jwgoerlich on March 20, 2007, 7:22 am
Please log in for more thread options
> First, can someone confirm that HKEY_LOCAL_MACHINE\SOFTWARE\Classes is the
> same as HKEY_CLASSES_ROOT? Why did Microsoft split the references to the
> same object as they did?

Actually, HKCR is a merged representation of HKCU\Software\Classes and
HKLM\Software\Classes. The permissions you see in HKCR come from these
keys. The reason that both the current user and the machine are
represented is for things like roaming profiles and terminal services.
This is called per-user class registration, where the user's hive can
contain the class information for the application.

I suspect that the split reference is for much the same reason there
is so many strange things about the registry: backwards compatibility.
WinNT 3x and 4 required HKCR.

J Wolfgang Goerlich


Incidentally, for a good read on what I mean by strange registry hold-
overs, see the following blog entry:

The long and sad story of the Shell Folders key
http://blogs.msdn.com/oldnewthing/archive/2003/11/03/55532.aspx



Posted by Will on March 20, 2007, 7:33 pm
Please log in for more thread options
>> First, can someone confirm that HKEY_LOCAL_MACHINE\SOFTWARE\Classes is
>> the
>> same as HKEY_CLASSES_ROOT? Why did Microsoft split the references to the
>> same object as they did?
>
> Actually, HKCR is a merged representation of HKCU\Software\Classes and
> HKLM\Software\Classes. The permissions you see in HKCR come from these
> keys. The reason that both the current user and the machine are
> represented is for things like roaming profiles and terminal services.
> This is called per-user class registration, where the user's hive can
> contain the class information for the application.
>
> I suspect that the split reference is for much the same reason there
> is so many strange things about the registry: backwards compatibility.
> WinNT 3x and 4 required HKCR.

Thank you very much for that explanation. What a completely bizarre entity
this is. I am not articulating it well but I was seeing different DACLs
spread throughout HKCR, some of which appeared to tie to HKCU and others of
which appeared to be single DACLs for the computer. Now it is clearer why.
I had created SACL for all failures on these entities, and I was trying
resolve failed security audits on many of these entities.

--
Will



Similar ThreadsPosted
ntfs permissions, ownership, adding permissions January 13, 2006, 2:03 pm
Share permissions conflicting with NTFS permissions May 18, 2006, 1:16 pm
Permissions December 8, 2005, 2:09 pm
IIS permissions January 24, 2006, 6:50 pm
Permissions July 13, 2006, 5:09 pm
Permissions August 11, 2006, 12:29 pm
How should I do this? February 26, 2008, 3:29 am
COM+ Permissions February 29, 2008, 11:22 am
c:\ drive permissions June 23, 2005, 5:10 pm
Folders and permissions September 29, 2005, 5:35 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap