Beware of Cascading Deletes in WSS/MOSS

[Update: 09-28-2007 – Actually the conclusion is this is NOT a bug, but by design behavior for this release.  The SPM that I emailed when I discovered this, got the this issue mixed up with some other bugs that were being fixed and confirmed incorrectly originally. 

Please note, that the SharePoint Product Managment team is is definitely interested in any customer feedback to consider for improvements…]

[Update: 04-30-2007 – I confirmed that this is indeed a bug in SharePoint, and is “NOT” expected behavior or by design.  A fix is being worked on to correct this behavior, and once complete I was informed that the fix would also be sent to me to test the results with in my scenario.  Once I get it, I’ll update this posting as well with the status.] 

This is one of those issues that if you are not aware of, can cause an enormous amount of confusion for your IT staff, and grief from your users.  I encountered this finding earlier this week and thought it was at the scope of the web you’re working on, but found it also affects all webs underneath “DEPENDING” on your inheritance structure.

Todd Bleeker and I had tons of email on this a short while ago with both of us being “EXTREMELY” surprised by this behavior when I found it.

I’ll use his simple statement of the problem, then explain to you what’s going on, because if you’re like me, you have to either A) See a visual representation of it or B) Perform the same steps yourself to see it.  After typing this entire post out, it can still be very hard to follow, so I encourage you to do your own testing.  It just makes me realize how helpful DeliverPoint 2007 is going to be.

So, as Todd states it:

When a [grand]child site is inhering permissions from its [grand]parent, non-site securable objects that have unique permissions are affected by a delete on a site that is defining permission for that hierarchy.

So imagine this site collection structure:

Mind you I’m no artist when it comes to expressing this graphically :), but the legend in the top right hopefully explains enough.

A is the root web of the site collection, and A1 and A2 or subwebs of A,

A3, A4 and A5 are subwebs of A1, and A6 and A7 are subwebs of A2

Red indicates where we have unique security defined (Security inheritance is broken)

The small notepad looking icons at the bottom are individual items within the yellow folders within a list on each web.  For the purposes of this example, I’m calling out individual List Items, but the problem exists whether the object in question is a List/Document Library, a folder within a document library, or an item within a list/folder, etc.  It boils down to every place that the ISecurableObject interface is exposed and where you can set unique security in SharePoint.

Imagine, that in each place where we have unique security defined, a given user has some sort of unique permission levels.  For this example, let’s assume the user is MYDOMAIN\jdoe

On the top level web (A), jdoe has the Read permission level set, therefore on A1, A3, and A5 his permission level is “Read” via inheritance. (He could even have the implicit “Limited Access” permission level if he was never granted direct rights on A for that matter)

On A2, he has Contributor Rights, and on A4 we’ve broken inheritance at the web level also and gave him Design rights.

Now, for each individual list item noted above, he has the “Full Control” permission level, because he really needs to do anything to that item he wants.

Let’s say you come along and decide you really don’t want him having “Read” access at all, and you only want him to retain his “Full Control” on the items in question.

You can’t directly assign a user the “Limited Access” permission level, so your only choice is to remove him from A and every other place other except for the list items, so you start by removing him from A

You move on to A2, and remove him there as well, then you visit A1. 

There’s of course nothing to do at A1, because A1 inherited its permissions from A, therefore by removal from A, you have removed his rights from A1, so you skip past A3, A5, A6 and A7.

Now, you visit A5 and remove his rights from there.

MYDOMAIN\jdoe now only has “Full Control” from all the individual items above right? 

Nope 🙂

If you removed the user from A, A2 and A4, jdoe has absolutely no rights whatsoever in the entire site collection.

If you went back and ONLY remove jdoe from A, then jdoe ONLY has rights on the list items contained within A4, A6, and A7 and he was removed from unique security of the list items contained within A3 and A5

The “X”  indicates where the “Gotcha” manifests itself.

Therefore non-site securable objects that have unique permissions are affected by a delete on a site that is defining permission for that hierarchy.  Therefore it’s important to TRULY understand your site/list/folder/inheritance structure

Oh, but there’s more!

Keep in mind, that if you had unique security on a list, and the item also had unique security, removing the user from the list, removes them from all items contained in the list regardless if the subitems are inheriting or not, which is different from web level security inheritance.  (Web level unique security blocks the cascading delete)

So, if you have the following:

WebWithUnique->SubWebInheriting->List->Folder->ItemWithUnique

Removing a user from WebWithUnique removes the user from ItemWithUnique if the user had permissions there, because SubWebInheriting does not break the inheritance chain, thus the “ItemWithUnique” is treated as a child item to WebWithUnique although it’s contained in SubWebInheriting as far as permissions are concerned.

where as

WebWithUnique->SubWebUnique->List->Folder->ItemWithUnique

Removing a user from WebWithUnique would NOT cause the user to be removed from ItemWithUnique because SubWebUnique breaks the “Web” level security inheritance.

yet given the following:

WebWithUnique->SubWebInheriting->ListWithUnique->FolderInheriting->ItemWithUnique

If you remove a user from ListWithUnique, the user is also removed from ItemWithUnique (If the user exists there) even though FolderInheriting resets the inheritance chain.

Believe it or not, I actually see why you “WOULD” want to remove a user from an uniquely secured object implicitly when you remove the user from a grandparent object (For instance, removing the user from a List, you really want the user removed “FROM THE LIST”)

But for it to “Jump” past web level boundaries and affect your lists/folders and items that had unique security buried within was completely unexpected.  Then to find that this would ONLY occur across webs where the security was inherited at the web level (But yet still unique at the list/folder and item level)

Oh, but so much more!

Consider the following scenario:

WebWithUnique->SubWebUnique->ListInheriting->FolderUnique->FolderInheriting->ItemUnique

Let’s pretend that at FolderUnique we add User1 with Design rights, then at ItemUnique we break inheritance again, and and remove User1, but add User2 with Contribute rights.

When you look at SubWebUnique, you’ll see both User1 and User2 with Limited Access.

Now, Select “Actions” and “Inherit Permissions” on SubWebUnique to re-inherit from WebWithUnique.

If you go back and look at the permission settings for FolderUnique and ItemUnique, you’ll also notice that the unique security is wiped from there, and they are reset back to inherit, therefore all child items of the “Webs” security are reset, because when you said “Inherit” It causes ALL Unique inheritance in the web to be wiped out, not just the Web level.

Now, it gets even worse.  Try this experiment out yourself

Start with the following:

WebWithUnique->SubWebInherits->ListInheriting->FolderUnique->FolderInheriting->ItemUnique

Add User 1 with Full Control to ItemUnique

Break inheritance at SubWebInherits and add User2 with Read rights or something (You’ll notice that User1 was given Limited Access all the way up to the grandparent site), so now your structure is as follows:

WebWithUnique->SubWebUnique->ListInheriting->FolderUnique->FolderInheriting->ItemUnique

Go back to SubWebUnique and re-inherit permissions.

You’ll notice that you’ve lost all unique permissions defined on any list/folder/item period within the subweb and any web that has web level inheritance.

In closing

I know this posting is extremely difficult to follow, but feel it’s important to share, even if you find it difficult to follow my examples.

 – Keith