some unexpected acl inheritances? output of cacls

Discussion in 'Security Software' started by john.ruckstuhl, Aug 29, 2011.

  1. I make a dir "c:\zoo" and I'm surprised by two of the ACLs as reported
    by cacls.

    1. Where does the 3rd ACL "BUILTIN\Adminstrators:F" come from? It
    isn't inherited, it's not present on the parent dir.
    2. Why does the 4th ACL "CREATOR OWNER:(OI)(CI)(IO)" still have
    "(IO)"? That is, the "(IO)" is on the ACL for the parent dir, but
    when it's inherited, shouldn't it lose the "(IO)"?
    I'm misunderstanding something...

    This on Windows Server 2003. The user making "c:\zoo" is in the
    "Administrators" group.
    Thanks for any guidance
    John R.

    C:\>cacls c:\
    c:\ BUILTIN\Administrators:(OI)(CI)F
    NT AUTHORITY\SYSTEM:(OI)(CI)F
    CREATOR OWNER:(OI)(CI)(IO)F
    BUILTIN\Users:(OI)(CI)R
    BUILTIN\Users:(CI)(special access:)
    FILE_APPEND_DATA

    BUILTIN\Users:(CI)(IO)(special access:)
    FILE_WRITE_DATA

    Everyone:R


    C:\>mkdir c:\zoo

    C:\>cacls c:\zoo
    1. c:\zoo BUILTIN\Administrators:(OI)(CI)F
    2. NT AUTHORITY\SYSTEM:(OI)(CI)F
    3. BUILTIN\Administrators:F
    4. CREATOR OWNER:(OI)(CI)(IO)F
    5. BUILTIN\Users:(OI)(CI)R
    6. BUILTIN\Users:(CI)(special access:)
    FILE_APPEND_DATA

    7. BUILTIN\Users:(CI)(special access:)
    FILE_WRITE_DATA



    C:\>
     
    john.ruckstuhl, Aug 29, 2011
    #1
    1. Advertisements

  2. From:

    http://technet.microsoft.com/en-us/library/bb457115.aspx

    How Access Control Is Applied to New Objects

    [...]

    If the parent object has no inheritable ACEs—for example, if the file is
    being created in the root directory—the operating system asks the object
    manager to provide a default DACL.

    If the object manager does not provide a default DACL, the operating
    system checks for a default DACL in the access token belonging to the
    subject (the user, for example).

    If the subject’s access token does not have a default DACL, the new
    object is assigned no DACL, which allows Everyone unconditional access.

    Warning Failure to set DACLs or setting DACLs improperly might have
    undesirable consequences. For example, an empty DACL, where neither
    Allow nor Deny has been configured, denies access to all accounts. On
    the other hand, if there is no DACL then all accounts have full access.
     
    FromTheRafters, Aug 29, 2011
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.