How do the names in the file security dialog map to access control masks?


When you call up the file security dialog, you'll see options like "Full Control" and "Read and Execute". That's really nice as friendly names go, but when you're digging into the security descriptor, you may need to know what those permissions really map to when it comes down to bits.

First, the summary attributes:

Friendly name Access mask Inheritance
Full control FILE_ALL_ACCESS CONTAINER_INHERIT_ACE + OBJECT_INHERIT_ACE
Modify FILE_GENERIC_READ | FILE_GENERIC_WRITE | FILE_GENERIC_EXECUTE | DELETE CONTAINER_INHERIT_ACE + OBJECT_INHERIT_ACE
Read and execute FILE_GENERIC_READ | FILE_GENERIC_EXECUTE CONTAINER_INHERIT_ACE + OBJECT_INHERIT_ACE
List folder contents FILE_GENERIC_READ | FILE_GENERIC_EXECUTE CONTAINER_INHERIT_ACE
Read FILE_GENERIC_READ CONTAINER_INHERIT_ACE + OBJECT_INHERIT_ACE
Write FILE_GENERIC_WRITE & ~READ_CONTROL CONTAINER_INHERIT_ACE + OBJECT_INHERIT_ACE

If you go to the Advanced view, then you get much more precise control:

Friendly name Access mask
Traverse Folder / Execute File FILE_TRAVERSE == FILE_EXECUTE
List Folder / Read Data FILE_LIST_DIRECTORY == FILE_READ_DATA
Read Attributes FILE_READ_ATTRIBUTES
Read Extended Attriibutes FILE_READ_EA
Create Files / Write Data FILE_ADD_FILE == FILE_WRITE_DATA
Create Folders / Append Data FILE_ADD_SUBDIRECTORY == FILE_APPEND_DATA
Write Attributes FILE_WRITE_ATTRIBUTES
Write Extended Attributes FILE_WRITE_EA
Delete Subfolders and Files FILE_DELETE_CHILD
Delete FILE_DELETE
Read Permissions READ_CONTROL
Change Permissions WRITE_DAC
Take Ownership WRITE_OWNER

(In the Advanced view, you control inheritance from the "Apply to" drop-down combo box.)

Note that the "Delete Subfolders and Files" and "Delete" attributes together determine whether you can delete a file or subdirectory: You can delete an item either if you have DELETE permission on the item or if you have DELETE_CHILD permission on its parent. This "combo" allows you to set up a directory where everybody can create files and can delete files that they have created, while still retaining the ability as the directory's owner to delete any file in it. You do this by granting yourself DELETE_CHILD permission on the directory and granting DELETE to CREATOR_OWNER as an inheritable attribute. Since you have DELETE_CHILD permission, you can delete anything in the directory. And since the creator/owner has DELETE permission, people can delete the files that they themselves created.

[Update 2pm: INHERIT_ONLY_ACE should be OBJECT_INHERIT_ACE.]

Comments (9)
  1. AndyC says:

    Brilliant! I was actually looking for exactly this information a while back and ended up giving up and just cobbling together something that covered the simple cases. Thanks Raymond.

  2. JamesNT says:

    This will prove very useful to me as well.  Thank you, Mr. Chen.

    JamesNT

  3. mikeb says:

    The WinXP "Help and Support Center" has a topic on Permissions that has links with similar descriptions (but still not nearly as detailed as what Raymond provided here) of the meanings of the terms used in the security dialog for all types of objects, including:

     – file & folders (what Raymond described above)

     – Shares

     – Registry keys

     – Services

     – Printers

     – Term Serv connections

     – Group policy objects

     – WMI objects

    Even though the descriptions in WinXP help don’t go to the level of detail saying which Win32 identifiers map to the permissions in the UI, they do get detailed enough that you can usually figure out the mappings.

  4. Pavel Lebedinsky says:

    Purpose: Having a common ‘temp’ directory that anybody can write to and in which one can only read/modify/delete his/her files.

    %windir%temp already works like this. It gives create file rights to BUILTINUsers and full control to creator/owner.

  5. Tom says:

    Although it’s probably not shell related, I’d be more interested to know how GENERIC_READ and GENERIC_WRITE permissions map to ACLs.  From what little research I’ve done, it appears that various subsystems (object manager, file system, etc) have tables that map the GENERIC_XXX to specific permissions, but I haven’t been able to find all the mappings.

  6. Prem says:

    I believe this "owner can delete" concept doesn’t entierly apply. If a user creates a subdirectory and denies permission to the directory, the owner can’t delete the directory and the files beneath it. Is there any workaround for this?

    Say if I want to implement a directory where any user can create/delete files but I have full access to the files/folders underneath. Assuming I don’t have admin rights..

  7. Nawak says:

    *Thanks* a lot Raymond!

    With that info, I managed, at last, to do what I always wanted: create a common temp directory for all users! Previously, I relied on the fact that there was always a program with a open temp file to deny me the temp directory deletion (I have a script to delete its content that does a "rd /s")

    Now I truly don’t have the right to delete it.

    For anybody who’s interested, and for my future use I’m sure, here is the purpose and how to do it:

    Purpose:

    Having a common ‘temp’ directory that anybody can write to and in which one can only read/modify/delete his/her files.

    I set it up so that administrator is also impacted, so you will have to have another special account+ACL if you want to easily clean it.

    In my example, the temp directory in question will be C:temp

    How to do it:

    – On the parent of the ‘temp’ directory (C:), remove the "Delete subfolders & file" permission from the users you want this method to apply. In my case, since "Users" only have Read/Execute permission on C:, this means that I only remove this permissions from the Administrators group(*).

    – Still on the parent (C:), add a new ACL for "CREATOR" that will apply only to contained files and subfolders. For this ACL, only set the "Delete" permission.

    – Create the temp directory.

    – Remove the ACL inheritance

    – Make effective the following permissions:

     – Admin group/This folder only: full control minus delete and delete children

     – Users group/This folder only: read/execute plus file and folders creation

     – CREATOR/This folder and everything inside: full control

    I hope I didn’t forget anything. Anybody, please feel free to correct me if this method is wrong in any way and thanks again Raymond!

    (*) I had previously removed my administrator login name from the list on C: since its right do not, in my opinion, need to be explicitely specified as they are not different from those of the group Administrators… I thought it was a duplicate entry.

  8. AndyC says:

    "Say if I want to implement a directory where any user can create/delete files but I have full access to the files/folders underneath. Assuming I don’t have admin rights.."

    If you don’t grant the WRITE_DAC permission on child objects that should do it, shouldn’t it? Since they won’t be able to alter the permission, you’ll always have access.

    Alternatively you could give the account that needs to delete them the Take Ownership permission, though that’s a little heavy handed.

  9. Nawak says:

    >Nawak:

    > Purpose: Having a common ‘temp’ directory that anybody can write to and in which one can only read/modify/delete his/her files.

    Pavel:

    %windir%temp already works like this. It gives create file rights to BUILTINUsers and full control to creator/owner.

    Well, mine doesn’t work like this. I don’t remember messing with its permissions but maybe I did. Mine is setup so that Users have Read/Execution access to c:windowstemp. So they cannot create files in it but they can read Admin’s temp files! Looking at how stupid that situation is, I clearly must have done something wrong in the past…

    If I look at one of my newer PC, the situation is different, much closer to what I wanted, except that while Users can create files and have directory traversal permission, they can’t list its files, which disables my "rd /s" temp cleaning solution. The other problem is that Admins can read & delete Users’ files, but I can understand that my personal preference is not the default :)

Comments are closed.