Why not set FileSystemRights Synchronize permission?

Question

Coming from a .Net development background with not that much experience in (NTFS) file system security most of the rights in System.Security.AccessControl.FileSystemRights are pretty clear to me.

However, FileSystemRights.Synchronize is an exception. From the documentation:

Specifies whether the application can wait for a file handle to synchronize with the completion of an I/O operation.

Or as someone else explains it:

The Synchronize permission allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies only to multiple-threaded, multiple-process programs.

So my questions are:

1. Is the above clarification correct?
2. And if it is, why not set the Synchronize right (if read access is granted)?

Febrile

Answer 1

To answer my own questions after doing some research:

1. Yes, it is correct. To quote Microsoft's "Permissions Entry Dialog Box" help screen from the advanced edit permissions dialog:

[Synchronize] Allows or denies different threads to wait on the handle for the file or folder and synchronize with another thread that may signal it. This permission applies only to multithreaded, multiprocess programs.

2. You can't not set the Synchronize right through the user interface. It is always set with other rights. Only with the .Net API (and most likely others as well) you can choose not to set the Synchronize right.

These are the coarse permissions you can set in the permissions dialog and the FileSystemRights they include:

• Full control (select all coarse permissions):
  • FullControl (all FileSystemRights, including Synchronize)
• Modify (also selects Read & execute, List folder contents, Read, Write):
  • Modify
  • Synchronize
• Read & execute (also selects List folder contents, Read):
  • ReadAndExecute
  • Synchronize
• List folder contents:
  • ReadAndExecute
  • Synchronize
• Read:
  • Read
  • Synchronize
• Write:
  • Write
  • Synchronize

These are the granular permissions you can set in the advanced permissions dialog and the FileSystemRights they include:

• Full control:
  • FullControl (all FileSystemRights, including Synchronize)
• Traverse folder / execute file:
  • ExecuteFile
  • Synchronize
• List folder / read data:
  • ReadData
  • Synchronize
• Read attributes:
  • ReadAttributes
  • Synchronize
• Read extended attributes:
  • ReadExtendedAttributes
  • Synchronize
• Create files / write data:
  • CreateFiles
  • Synchronize
• Create folders / append data:
  • AppendData
  • Synchronize
• Write attributes:
  • WriteAttributes
  • Synchronize
• Write extended attributes:
  • WriteExtendedAttributes
  • Synchronize
• Delete subfolders and files:
  • DeleteSubdirectoriesAndFiles
  • Synchronize
• Delete:
  • Delete
  • Synchronize
• Read permissions:
  • ReadPermissions
  • Synchronize
• Change permissions:
  • ChangePermissions
  • Synchronize
• Take ownership:
  • TakeOwnership
  • Synchronize

Note that there are a few FileSystemRights that include other rights because of their bit mask. Those correspond to the rights you can set in the coarse permissions dialog. The FileSystemRights value and the other values they include:

• Read:
  • ReadPermissions
  • ReadAttributes
  • ReadExtendedAttributes
  • ListDirectory/ReadData
• ReadAndExecute (Read + ExecuteFile):
  • ReadPermissions
  • ReadAttributes
  • ReadExtendedAttributes
  • ListDirectory/ReadData
  • ExecuteFile/Traverse
• Write:
  • WriteAttributes
  • WriteExtendedAttributes
  • CreateDirectories/AppendData
  • CreateFiles/WriteData
• Modify (ReadAndExecute + Write + Delete):
  • ReadPermissions
  • ReadAttributes
  • ReadExtendedAttributes
  • ListDirectory/ReadData
  • ExecuteFile/Traverse
  • WriteAttributes
  • WriteExtendedAttributes
  • CreateDirectories/AppendData
  • CreateFiles/WriteData
  • Delete
• FullControl: includes all.

There are also a few FileSystemRights that share the same value and are used interchangeably. They are:

• ListDirectory, ReadData: 1
• CreateFiles, WriteData: 2
• CreateDirectories, AppendData: 4
• ExecuteFile, Traverse: 32

Febrile

FileSystemRights enum ? – Vie

@Vie Yes, that's System.Security.AccessControl.FileSystemRights. – Febrile

Note that in icacls, when you deny write, you also deny synchronize, which ends up making the file or folder unreadable. And there's no way to tell through icacls, although cacls will tell you. – Haulage

The "why not set the Synchronize right (if read access is granted)?" question hasn't been answered (assuming it does not refer only to the Windows file/folder security UI, but also about doing it programmatically using a Windows file permissions API ). I have always seen that permission enabled when read access is granted. – Fervid

Answer 2

@js2010 not using regular/simple deny rights W & D with icacls, but the "other ones" seems to do the job (ie not denying Synchronize right at the same time (ie render directory not accessible at all)) : icacls.exe "$DIR" /deny *S-1-1-0:(OI)(CI)(WEA,WA,DC,AD,WD,WDAC,DE) #HTH (my reputation is not strong enough just to comment your comment)

Mezzosoprano

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Hargreaves

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Western