Which access rights bits belong to whom?

Date:December 4, 2003 / year-entry #150
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20031204-00/?p=41623
Comments:    2
Summary:Each ACE in a security descriptor contains a 32-bit access mask. Which bits belong to whom? The access rights mask is a 32-bit value. The upper 16 bits are defined by the operating system and the lower 16 bits are defined by the object being secured. For example, consider the value 0x00060002 for the access...

Each ACE in a security descriptor contains a 32-bit access mask. Which bits belong to whom?

The access rights mask is a 32-bit value. The upper 16 bits are defined by the operating system and the lower 16 bits are defined by the object being secured.

For example, consider the value 0x00060002 for the access rights mask. This breaks down as the system-defined access rights WRITE_DAC (0x00040000), READ_CONTROL (0x00020000), and one object-defined access right 0x0002.

The object-defined access right 0x0002 depends on the object. This particular access right might mean any of the following:

meaning if the object is a...
FILE_WRITE_DATA file
FILE_ADD_FILE directory
PROCESS_CREATE_THREAD process
THREAD_SUSPEND_RESUME thread
JOB_OBJECT_SET_ATTRIBUTES job object
EVENT_MODIFY_STATE event
SEMAPHORE_MODIFY_STATE semaphore
TIMER_MODIFY_STATE timer
IO_COMPLETION_MODIFY_STATE I/O completion port
KEY_SET_VALUE registry key
TOKEN_DUPLICATE token
WINSTA_READATTRIBUTES windowstation
DESKTOP_CREATEWINDOW desktop

or it could mean something else entirely if it's an object of a type not listed above.

If you ask the ConvertSecurityDescriptorToStringSecurityDescriptor function to convert a security descriptor to a string security descriptor, it tries to guess what the object is, but since there is so little information to go on, it usually guesses wrong. The access rights mask above, for example, would be rendered by SDDL as "DCRCWD". The rights RC = READ_CONTROL, WD = WRITE_DAC are standard across all objects, so there is no guessing there. But SDDL guessed that 0x0002 was DC = ADS_RIGHTS_DS_DELETE_CHILD.

Notice that there are some system-defined access rights that are named "GENERIC", such as GENERIC_READ and GENERIC_WRITE. Each object exposes different "read-like", "write-like", and possibly "execute-like" access rights (for example, registry keys have KEY_QUERY_VALUE and KEY_SET_VALUE), but they all have to define which ones are read-like, which ones are write-like, and which ones are execute-like, so that you can request one of the GENERIC access masks and get access appropriate to the type of object you are opening.


Comments (2)
  1. Chaz says:

    "If you ask the ConvertSecurityDescriptorToStringSecurityDescriptor function to convert a security descriptor to a string security descriptor, it tries to guess what the object is, but since there is so little information to go on, it usually guesses wrong."

    This is one of my favourite lines yet. Why I keep coming back to Raymond.

  2. Anonymous says:

    ConvertSecurityDescriptorToStringSecurityDescriptor… Jesus Christ man that function is 51 characters long!

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index