Why does Limited Access appear in the group permissions of unrelated groups?

Question

I thought Limited Access (LA) applied to branches and not leaves. My understanding is that if you break inheritance and assign special permissions to some item in the site hierarchy, that LA is inferred. It permits a user who would not otherwise be permitted to get to an item (based on barring parent access) to get to the item he's been explicitly permitted to access.

We have a list with fine-grained permissions assigned based on item-level metadata. (We have since learned of the warnings surrounding this practice.) When an item is created/updated a workflow runs to Replace Permissions. This disregards the List permissions by whitelisting access.

Let's flesh out a generic scenario to illustrate the problem.

We have a list Cards which has Rank and Suit columns. The Suit column is used to whitelist access via workflow to a group of the same name (e.g. Heart). We create two Card items: King of Hearts and Ace of Spades. When viewing group permissions on the "Heart" group we see the expected permission on the King of Hearts. The confusing part is that we also see a Limited Access permission on Ace of Spades which, as far as I can tell, has no discernible relation to the Heart group.

How could this problem arise? Each Card is a leaf. As far as I know there is nothing below it in the hierarchy to account for a need to infer LA on it.

To temporarily correct the problem, we can delete unique list permissions, stop inheriting list permissions (toggle), and rerun the workflow on each item (reassign permissions). Adding new items later causes the problem to reappear. We can toggle/reassign again, but why should we have to do something so unusual?

Answer 1

While I can answer the original question, it doesn't solve our dilemma.

The problem is timing.

We have a blank Cards list that has broken inheritance.

1. View group permissions for Heart, Diamond, Club, and Spade. Note that from the context of each group, no access will have been stamped on the Card list itself.

2. Create card King of Hearts and then view group permissions for Heart. It will have the desired read access to the King and LA on the Cards list itself. This newly introduced LA stamp (the villain) will end up causing strife. The other groups remain in good order.

3. Create card Ace of Spades and then view group permissions for Spade. It will have the desired read access to the Ace and a new LA stamp on the Cards list, just like above. Revisit the permissions for Heart. Surprisingly, it too will have access to the Ace card. It shouldn't. This happens as a result of the villain. Its LA is passed on to the Ace.

As you define additional cards, the issue will propagate. Essentially, groups that have already gained the LA stamp on the Cards list will continuing picking up access to items they shouldn't.

It is possible to restore permission to a pristine state. You have to add the tainted group to Card list (e.g. Heart) and then remove it, and then rerun the permissions workflow on each item. This does not prevent permissions from devolving again.

This appears to be a grievous SharePoint design flaw since it demands a workaround for a typical fine-grained permissions use case.