NTFS Permissions - Create Files and Folder but prevent Deletion and Modification

Question

Objective: A shared folder to which users can create files but not modify or delete them. Users should also be able to create subfolders.

I have granted my security group the following advanced NTFS permissions:

• Traverse Folder/Execute File
• List Folder/Read Data
• Read Attributes
• Read Extended Attributes
• Create Files/Write Data
• Read Permissions

Through a process of trial and error, I have found that by NOT granting 'Write Attributes', this has the effect of preventing a user from modifying/deleting existing files (which is what I want). However, I would really like an explanation as to precisely why this works. The only theory I have is that the deletion/modification of a file changes the attributes of the file? Here is a discussion along same lines.

EDIT - The second part of my question is irrelevant, I thought that I had only selected 'Create Files/Write Data' but I did also have 'Create Folders/Append Data' selected as well.

Further more, I want users to be able to create subfolders within the root, and I have found that by granting 'Create Files/Write Data', this allows just that. But again, the name suggests this permission should just permit the creation of files, not folders, so I don't understand why it is working? Microsoft's explnanation of the 'Create Files/Write Data' attribute is "For folders, specifies whether a user can create files within the folder. For files, specifies whether a user can change files or overwrite data." There is no mention of the ability to create subfolders within a folder?

So basically, I've achieived what I set out to do but don't understand why it works?

Answer 1

Through a process of trial and error, I have found that by NOT granting 'Write Attributes', this has the effect of preventing a user from modifying/deleting existing files (which is what I want). However, I would really like an explanation as to precisely why this works.

This is a function of precisely how a file modification occurs. When you modify a file, the operating system doesn't actually modify the file you're editing. It replaces the file you're editing with the copy you changed. So, essentially, a file modification takes a copy of the original file, loads it into memory (where you modify it), deletes the original file, and creates a new file with the same name in the same place. This is why NTFS Delete permissions are required to modify files - in fact, if you check the Advanced permissions on an NTFS object, there is no Modify permission - a modification is really just a delete and a write.

So, in order to create that new copy of a file, it has to write the file attributes of this new file... and, of course, writing attributes requires the Write attributes NTFS permission. So that is why you can't modify a file without having the Write attributes NTFS permission.

Specifically, thanks to a chat with Fitzroy, the NTFS file attribute that needs to be written under the user's security context (that can't be, without the Write Attributes permission), when modifying a file, but not when creating a completely new one, would be the file's LastModificationTime. This is a part of the Standard Information attribute, according to one of the Microsoft Core Team developers.

Answer 2

It's true: not having the 'Write Attributes' permission results in the user being unable to modify its files. And according to Microsoft documentation it doesn't make sense. But modifying a file doesn't imply deletion and recreation of it. When an application opens a file for modification the operating system doesn't delete the file. But, what the OS does is locking the file to prevent concurrent modification. My guess is that locking the file falls under 'changing file attributes' concept. Thus, not being able to change attributes results in not being able to modify the file.

For the second part of your question, I can't reproduce that. There are two different permissions which apply to a folder: 'Create Files/...' and 'Create Folders/...' and they worked according to documentation during my tests.