INFO: Incorrect Configuration Can Orphan COM Servers

 Last reviewed: July 1, 1997
Article ID: Q170915
The information in this article applies to:
  • Microsoft OLE Libraries 4.0 included with: - Microsoft Win32 Software Development Kit (SDK)

SUMMARY

If the launch and access permissions of a secure COM server are configured incorrectly, a situation might arise where the COM server is launched, but it is never shut down. This happens when a client's user account is allowed launch permissions to the server but not access permissions. Because no valid client/server connection is ever established, the automatic garbage collection mechanism built into COM is not implemented in this case and the server may be left running forever.

MORE INFORMATION

Consider the case where a client's account is in the launch permissions list of a COM server, but it is missing from the access permissions list. If an authenticated COM session is to be established between the client and the server, COM needs to check both launch and access security. Since the client has launch permissions, COM launches the server. The server calls CoRegisterClassObject() to register its classes. COM then tries to call the server while impersonating the client. The call is never dispatched into the server code due to the initial security check failing. No interfaces are marshaled and an Access Denied error is returned to the client. Since no objects are created or properly marshaled, no garbage collection is subsequently performed. This may result in the COM server process being orphaned.

The server process and associated COM class objects will be orphaned if:

  1. It is a single-use server (registered with REGCLS_SINGLEUSE).

-or-

  1. It is configured to run as the launching user.

-or-

  1. In other cases (non-single-use, non-run-as-launching-user), if no user with access permission subsequently tries to activate the server and then shuts it down properly when done.

Correctly configuring the COM server is the solution to this problem. Clients that are allowed launch permissions on a server (AppID) must also be given call permissions.

Notice that the opposite is not true. That is, it is completely reasonable to have clients with access permissions (can call a running server) but no launch permissions (can't start a non-running server). Indeed, it is precisely for this scenario that COM separates the two ACLs.

REFERENCES

For additional information, please see the following article(s) in the Microsoft Knowledge Base: 

   ARTICLE-ID: Q158508
   TITLE     : INFO: COM Security Frequently Asked Questions

   ARTICLE-ID: Q169321
   TITLE     : INFO: COM Servers Activation and NT Windows Stations

Keywords : BseRegistry BseSecurity LeTwoCom LeTwoDCom
Issue type : kbinfo

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 1, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.