Why „Restricted Modify“ might not be a good idea and how to fix it

SolarWinds ARM offers a permission called „Restricted Modify“ and at its base it is a good idea. It is a permission set which hinders the user from deleting the folder it is set on, but the user still has normal modify permission within the folder. This helps you to protect your file server structure to be interrupted too much and can stay the same.

Now we have seen a behaviour with it which is not wanted and can cause more trouble than it helps.

Preconditions

• Users have „Full Control“ share permissions
  
• You have a (source) folder with „Restricted Modify“ for your users
  
• You (target) folder with normal modify permissions for your users.
  

For demonstration purpose I use a very simple structure. A share („CompanyShare“) with two subfolders, „Folder A“ and „Folder B“.

„Folder A“ has the „Restricted Modify“ for users and this is how the individual permission flags look like:

These are the permissions on the file in „Folder A“:

As you might have noticed the permission „Delete subfolders and files“ is missing. This is correct since this flag is on the folder and not the file. The „Delete“ flag is not set on the file since it still obeys the laws of inheritance:

The permission comes from „Folder A“.

The Problem

Now you move a file from „Folder A“ to „Folder B.“

These are the permission on the file after the move to „Folder B“:

They look the same as on the source folder.

But there is one crucial difference: the inheritance

The system can no longer identify from where the permission is inherited and just states „Parent Object“ because that is all it can detect in the ACL. This is now a „Broken ACL“ (also known as „Broken Inheritance“).

A broken ACL is created when you move a file within a drive or share and the user who moves the file has not the permission to change the permission on that file in the source folder. The permission on the target folder does not matter. When a file is move the system tries to update the permissions on the file in the context of the user (or at least in the context of their permissions) Since modify does not offer this, the update will fail and the system silently continues.

This is bad, but most of the time not noticeable. Except when you use „Restricted Modify“.

Why? Because now it is impossible for the users to delete or rename the file since the „Delete“ permission is missing.

In „Folder A“ this was still possible due to the original permission the file inherited. Since there is no longer a way for the system to check this, it will assume the present permission is the definitive permission and will act accordingly.

„Broken Inheritance“ will not happen if you change the target share or drive when moving file.

How to fix this?

There is a simple way which overall will increase your security: change the share permission from „Full Control“ to „Change“. That is all you must do. The system will now always update the permissions.