Источник:
https://crmtipoftheday.com/1089/user...han-you-think/
==============
This one was discovered by my KPMG partners in crime
Fiona Whiteing and
Jijeesh Kunhiraman on a recent project. As you may know, for a record such as a Contact, if I own the record, I can see the child Activities whether my security role gives me permission or not. I do not know if this obscure exception to record level security has a name. I call it ‘inherited security’. In fact it also works for Team ownership; if I am a member of a Team which owns a Contact, I can see the Activities of that Contact whether my security role (or the Team’s security role) allows me to or not.
If you did not know the above, end here and walk away intellectually nourished by an informative tip. If you did know the above, here is the twist. Let us say you are a member of a Team which owns a Contact and you can see the associated Activities thanks to inherited security. Let is assume none of the Activities are yours. If I now give your User record’s Security Role User-level delete privileges to Activities, you can now delete all those child Activities. Even though they are owned by other people and you can only see them because the Activities are on a Contact, owned by a Team which you are a member, you still get to blow them away.
Somehow inherited security amplifies the User-level delete privilege to work on any child record it renders visible, regardless of the actual owner. Is this a bug? Maybe. My guess is, as inherited security pre-dates the introduction of Team ownership in Dynamics, the subtle nuances of the two combining were not fully tested and give rise to unusual results. The moral of this tip? If you are securing records and inherited security is involved, make sure you test everything within an inch of its life.
Источник:
https://crmtipoftheday.com/1089/user...han-you-think/