{"id":98995,"date":"2018-06-13T07:00:00","date_gmt":"2018-06-13T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=98995"},"modified":"2019-03-13T00:42:12","modified_gmt":"2019-03-13T07:42:12","slug":"20180613-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180613-00\/?p=98995","title":{"rendered":"Why does the CREATOR_OWNER SID sometimes reset itself to the object’s current owner rather than its original owner?"},"content":{"rendered":"

I noted some time ago that the CREATOR_<\/code>OWNER<\/code> security identifier (SID) is not a shorthand that refers to the object’s current owner. Rather, the CREATOR_<\/code>OWNER<\/code> SID is a template that is applied when the object is created<\/a>. When the template is applied, all occurrences of CREATOR_<\/code>OWNER<\/code> are replaced with the object’s current owner, and it is the replaced SID that controls access. Changing the object’s owner doesn’t cause these access control entries to be recalculated;¹ they continue to refer to the captured value. <\/p>\n

A customer observed this phenomenon when they created a folder with an inheritable access control entry (ACE) for CREATOR_<\/code>OWNER<\/code>. They observed that those access control entries were indeed propagated to child objects, with the CREATOR_<\/code>OWNER<\/code> changed to the object’s actual owner. Furthermore, if they went to the Security properties and changed the child object’s owner, the ACE was not recalculated to update the ACE’s SID from the old owner to the new owner. <\/p>\n

However (and this is the weird part), if they use the Security properties to make some unrelated change to the object’s access control list (ACL), then this has a side effect of recalculating the ACEs and updating the CREATOR_<\/code>OWNER<\/code>-sourced ACEs to refer to the new owner. <\/p>\n

This recalculation is not being done by the security infrastructure. It’s being done by the ACL editor. <\/p>\n

When you change the access control list for an item, the ACL editor calls Tree­Set­Named­Security­Info<\/code> and passes an ACL that consists only of the non-inherited ACEs, and it sets the UNPROTECTED_<\/code>DACL_<\/code>SECURITY_<\/code>INFORMATION<\/code> flag, which means “Oh, and also inherit ACEs from my parent, as if I were newly-created.” <\/p>\n

In other words, the ACL edit deletes all the ACEs that were obtained by inherance, and then creates new ACEs based on the current parent’s inheritable ACEs. <\/p>\n

The ACL editor is trying to be helpful, but it ends up being confusing. <\/p>\n

¹ What would this recalculation even mean if the object was moved to a new folder after being created, or if the containing folder’s access control list were modified in the interim? I guess you could have a bit somewhere in the ACE that says, “This was originally created from a template that used CREATOR_<\/code>OWNER<\/code>.” The closest thing to that is the INHERITED_<\/code>ACE<\/code> bit, which says “This ACE was autogenerated via inheritance,” but it doesn’t give any information as to what the original ACE was. Suppose the object’s current owner is Bob. If an ACE applies to Bob and has the INHERITED_<\/code>ACE<\/code> bit set, it could mean that the original template ACE’s SID was CREATOR_<\/code>OWNER<\/code> that was changed to Bob during template application because Bob was the original owner, or it could mean that the original template ACE’s SID was CREATOR_<\/code>GROUP<\/code> that was changed to Bob during template application because Bob was the original group, or it could mean that the original template ACE’s SID was Bob all along. <\/p>\n

\n","protected":false},"excerpt":{"rendered":"

It’s a snapshot, but you can ask for a new snapshot.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[104],"class_list":["post-98995","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-tipssupport"],"acf":[],"blog_post_summary":"

It’s a snapshot, but you can ask for a new snapshot.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98995","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=98995"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98995\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=98995"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=98995"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=98995"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}