Hi,
Spotted in MSDN web page DCOM Security Enhancements in Windows XP Service
Pack 2 and Windows Server 2003 Service Pack 1
[
http://www.yqcomputer.com/ ]:
"To provide backward compatibility, an ACL can exist in the format used
before Windows XP SP2 and Windows Server 2003 SP1, which uses only the
access right COM_RIGHTS_EXECUTE, or it can exist in the new format used in
Windows XP SP2 and Windows Server 2003 SP1, which uses COM_RIGHTS_EXECUTE
together with a combination of COM_RIGHTS_EXECUTE_LOCAL,
COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL, and
COM_RIGHTS_ACTIVATE_REMOTE. Note that COM_RIGHTS_EXECUTE must always be
present; the absence of this right generates an invalid security descriptor.
Also note that you must not mix the old format and the new format within a
single ACL; either all access control entries (ACEs) must grant only the
COM_RIGHTS_EXECUTE access right, or they all must grant COM_RIGHTS_EXECUTE
together with a combination of COM_RIGHTS_EXECUTE_LOCAL,
COM_RIGHTS_EXECUTE_REMOTE, COM_RIGHTS_ACTIVATE_LOCAL, and
COM_RIGHTS_ACTIVATE_REMOTE. For more information, see DCOM Security
Enhancements in Windows XP Service Pack 2 and Windows Server 2003 Service
Pack 1 [
http://www.yqcomputer.com/ ] ."
In the last sentence of the quote the cross reference to itself for more
information sent my head reeling into an infinite recursive loop! Let's hope
that the DCOM security code is more thoroughly debugged than the
documentation! Otherwise however high a level of security is built into
DCOM, the developer without a unified complete and clear definition of the
security rules applied by DCOM to refer to and analyse performance against
will not be able to satisfy himself/herself about the level of security
actually being achieved. In the absence of such a unified definition there
is a high risk the objective of the security framework may be defeated
because the administrator or developer is compelled to uncomprehendingly
follow recipes known to work rather than applying a full understanding of
the security logic in order to arrive at a set of security settings that
are appropriate for his/her application.
Another suggestion: In view of the fact that each new version of Windows
makes changes to the DCOM security model, it would be helpful if every
article in the MSDN web site addressing COM and DCOM were to clearly
indicate the most recent version of Windows to which the article has been
updated. The updating of an article to a new version of Windows should where
possible be carried through to all articles cross-referenced in hyperlinks.
Otherwise we have the "DLL hell" syndrome repeated in the linking of
mutually incompatible article revisions.
Regards,
Enquiring Mind