How CREATOR_OWNER and CREATOR_GROUP Affect Security

Last reviewed: September 25, 1995
Article ID: Q126629
The information in this article applies to:
  • Microsoft Win32 Application Programming Interface (API) included with:

        - Microsoft Windows NT version 3.5
    

SUMMARY

This article discusses the CREATOR_OWNER and CREATOR_GROUP security identifiers (SID) and how they affect security.

MORE INFORMATION

When logged on, each user is represented by a token object. This token contains all the SIDs comprising your security context. Tokens identify one of those SIDs as a default owner for any new objects the user creates, such as files, processes, events, and so forth. Typically, this is the user's account (<domain>\<username>). For an administrator however, the default owner is set to be the local group "Administrators," rather than the individual's user account.

Each token also identifies a primary group for the user. This group does not necessarily have to be one the user is a member of (although it is by default) and it does not determine the objects a user has access to (that is, it isn't used in access validation decisions). However, by default it is assigned as the primary group of any objects the user creates. For the most part, the primary group is required simply for POSIX compatibility, but the primary group does play a role in object creation.

When a new object is created, the security system has the task of assigning protection to the new object. The system follows this process:

  1. Assign the new object any protection explicitly passed in by the object creator.

  2. Otherwise, assign the new object any inheritable protection from the container the object is created in.

  3. Otherwise, assign the new object any protection explicitly passed in by the object creator, but marked as "default."

  4. Otherwise, if the caller's token has a default DACL, that will be assigned to the new object.

  5. Otherwise, no protection is assigned to the new object.

In step 2, if the parent container has inheritable access-control entries (ACE), those are used to generate protection for the new object. In this case, each ACE is evaluated to see if it should be copied to the new object's protection. Usually, when an ACE is copied, the SID within that ACE is copied as is. The two exceptions to this rule are when CREATOR_OWNER and CREATOR_GROUP are encountered. In this case, the SID is replaced with the caller's default owner SID or primary group SID.

By default, users logging on to Windows NT are given a primary group of "Domain Users" (when logging on to a Windows NT Server) or the group called "None" (when logging onto a Windows NT Workstation system). Therefore, when you create an object in a container that has an inheritable ACE with the CREATOR_GROUP SID, you will likely end up with an ACE granting Domain Users some access. This may not be what you intended.


Additional reference words: 3.50
KBCategory: kbprg
KBSubcategory: BseSecurity


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: September 25, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.