I am developing some reporting for a series of Windows shares and I am not clear on the implementation details regarding permissions with deny types. While trying to calculate the resulting effective mask a user is subjected to after compensating for all share and ntfs permissions, it is not clear to me how to accomodate a deny type if present at the share level.
According to Permissions on a Shared Folder, the more restrictive permission takes precedence between the share and ntfs permissions and a deny type at the share level supersedes any permission at the ntfs level.
Consider the case where user-a has an explicit grant for Full Control
at both the share and ntfs level.
If a group which user-a is a member of is added to the shares acl, any combination of a deny, Read
, Change
or Full Control
manifests as no access at all for user-a. In addition, with the group set to Read
on the share permission, user-a cannot delete a file if the path is known programmatically.
Effectively, if the context accessing a share acquires a deny of any mask, all access is denied based on my tests.
What is the use case for three mask options with a deny when the least restrictive (read) prevents all access entirely? I am aware that you can set finer grained permissions programmatically, however why expose even 3 from the UI when they all behave the same?
What is the use case for three mask options with a deny when the least restrictive (read) prevents all access
. There isn't a use case.