IMO the reason permission repair was necessary and included in previous versions of OS X was because of poorly designed, written, and tested installer scripts from developers. Sandboxing of apps in iOS and OS X together with SIP (System, Integrity Protection) of the OS X kernel from non-sandboxed apps have made permission repair unnecessary and obsolete (unless you choose to disable SIP — but at that point you are on your own).
I'm either not making my point or not understanding your and V1's responses in relation thereto.
NOTE: changing the ACL can break an application or applications and is the likely explanation for what you reported in the original post in this thread.
That sounds like it's on target as respects the second error I reported...
User differs on "private/var/db/displaypolicyd", should be 0, user is 244.
Group differs on "private/var/db/displaypolicyd", should be 0, group is 244.
Repaired "private/var/db/displaypolicyd".
because the "repaired" item recurs after restarting,
but the first one, which has never recurred,
User differs on "Library/Bundles", should be 0, user is 501.
Group differs on "Library/Bundles", should be 0, group is 20.
Repaired "Library/Bundles".
doesn't seem to fit that mold, and I can't begin to guess how it arose; it's certainly not an area of OS X that I've ever touched on my own.
/Library isn't protected by SIP or anything else and can be written to indiscriminately, and permissions in that area are, therefore, vulnerable, but in removing permission repair functionality Apple has told us to ignore the vulnerability.
Unless I've totally missed something critical, that doesn't make any sense to me!
