Holy cow, I wrote a book!
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:
FILE_ALL_ACCESS
CONTAINER_INHERIT_ACE + OBJECT_INHERIT_ACE
FILE_GENERIC_READ | FILE_GENERIC_WRITE | FILE_GENERIC_EXECUTE | DELETE
FILE_GENERIC_READ | FILE_GENERIC_EXECUTE
CONTAINER_INHERIT_ACE
FILE_GENERIC_READ
FILE_GENERIC_WRITE & ~READ_CONTROL
If you go to the Advanced view, then you get much more precise control:
FILE_TRAVERSE == FILE_EXECUTE
FILE_LIST_DIRECTORY == FILE_READ_DATA
FILE_READ_ATTRIBUTES
FILE_READ_EA
FILE_ADD_FILE == FILE_WRITE_DATA
FILE_ADD_SUBDIRECTORY == FILE_APPEND_DATA
FILE_WRITE_ATTRIBUTES
FILE_WRITE_EA
FILE_DELETE_CHILD
FILE_DELETE
READ_CONTROL
WRITE_DAC
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.
DELETE
DELETE_CHILD
CREATOR_OWNER
[Update 2pm: INHERIT_ONLY_ACE should be OBJECT_INHERIT_ACE.]